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Revisions 
The CIP Networks Library Volume 5: CIP Safety Edition 2.3 contains the following changes 
from the previous Edition. Please see the change bars on the pages noted here for specific 
modifications. Note: Some of the pages within the ranges noted may not contain any changes. 
Chpt-Sect Pages Reason for Change 
EDS: Safety on a subset of ports 
7-2.2.2 7-27 ¢ Modify SRS206 to include Classx keyword, add format table 
7-2.2.2.1 7-27 ¢ _ Insert subsection for Classx example 
F—4.12 F-114 ¢ Modify SRS206 so it agrees with edit made in 7-2.2.2 
Safety Format Support in EDS 
7-22.24 7-28 ¢ Change "Extended Format" to "Safety Format" in Conn Mgr keywords table 
7-2.2.4.2.2 7-29 ¢ Change SafetyFormat value in first paragraph to "1" 
7-2.2.4.4 7-33 ¢ Change SafetyFormat value in EDS exmple to 3 
Missing NV column for DeviceNet Object 
5-3.1 5-8 ¢ Change caption and add NV column to Table 5-3.1 
Use of Config #1 and Config #2 in EDS Connection Manager Section 
5-53 ¢ Changed Attrib 10 Name & Description of Attribute fields to "Target Config Data" 
5-60 . rpeneet Config #1 to Proxy Config in two places and change Config #2 to Target Config in one 
place. 
oe 5-60 e Changed Config #2 to Target Config in five places 
5-6.2.1.13 
5-6.2.2.7 : is 
5-62.28 5-64,65 | Changed Config #1 and Config #2 to Target Config in two places 
7-23 7-30 e Changed Config #1 and Config #2 to Target Config in 4 places in Table 7-2.3 
3 to 250 Byte Complemented CRC calculation clarification 
a ¢ Remove "XOR OxFF" from last bullet of FRS43 and FRS369 
ry e Change "Actual" to "Complemented" & remove "XOR OxFF" from FRS43 & FRS369 
Safety Analog Device Type 
6-44 thru c 2 
6-7 650 © Insert new Device Profile for Safety Analog Device Type 
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Preface 
Organization of the CIP Networks Specifications 


Today, four networks - DeviceNet™, ControlNet™, EtherNet/IP™ and CompoNet™ - use the 
Common Industrial Protocol (CIP) for the upper layers of their network protocol. For this 
reason, ODVA manages and distributes the specifications for CIP Networks in a common 
structure to help ensure consistency and accuracy in the management of these specifications. 


The following diagram illustrates the organization of the library of CIP Network specifications. 
In addition to CIP Networks, CIP Safety™ consists of the extensions to CIP for functional 
safety. 
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This common structure presents CIP in one volume with a separate volume for each network 
adaptation of CIP. The specifications for the CIP Networks are two-volume sets, paired as 
shown below. 


The EtherNet/IP specification consists of: 

Volume 1: Common Industrial Protocol (CIP™) 
Volume 2: EtherNet/IP Adaptation of CIP 

The DeviceNet specification consists of: 

Volume 1: Common Industrial Protocol (CIP™) 
Volume 3: DeviceNet Adaptation of CIP 

The ControlNet specification consists of: 

Volume 1: Common Industrial Protocol (CIP™) 
Volume 4: ControlNet Adaptation of CIP 

The CompoNet specification consists of: 

Volume 1: Common Industrial Protocol (CIP™) 
Volume 6: CompoNet Adaptation of CIP 

The specification for CIP Safety™ is distributed in a single volume: 
Volume 5: CIP Safety 


The specification for integrating Modbus Devices is distributed in a single volume: 


Volume 7: Integration of Modbus Devices into the CIP Architecture 


Specification Enhancement Process 


The specifications for CIP Networks are continually being enhanced to meet the increasing 
needs of users for features and functionality. ODVA has implemented a Specification 
Enhancement Process in order to ensure open and stable specifications for all CIP Networks. 
This process is ongoing throughout the year for each CIP Network Specification as shown in 
the figure below. New editions of each CIP Network specification are published on a periodic 
basis. 


_ Members Develop Specification 


New Specification Enhancements in Special Interest 
Edition Published Groups (SIGs) 


Conformance Tests 


Undated Technical Review Board 


Reviews and Approves 
Specification Enhancements 


Member Review and 
Comment Ne 


Specification Enhancements 
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1-1 


1-2 


Introduction 


This specification identifies the functionality for a CIP safety network protocol. The scope of 
the design is a safety protocol used on message passing buses. 


This approach uses the safety processes and coding as recommended by The German Safety 
Bus Committee [1] for safety data transmission on a standard network. This method relies on 
providing measures for possible transmission errors as defined in pr EN50159-1 [2]. 


Background 


Traditional safety systems have relied on hardwired E-stops, interlock switches, dual contact 
actuators and dual contact actuators connected to safety relays to provide protection for 
operators at run time. These systems have worked reliably but have not kept pace with 
developments in technology. As control systems became more complex and control systems in 
production lines were interconnected, the task of developing a safety system with traditional 
components became increasingly difficult. Complex electronic devices such as mutable light 
curtains and robots also made the problem more difficult to solve. Recent studies have 
demonstrated that run time safety is no longer the primary cause for accidents. With the 
realization that machine maintenance poses the largest safety risk, the difficulty in creating a 
safety system for complex machines is daunting when approached with traditional components. 


Redundant Controllers, I/O and in some cases redundant networks have been used to solve 
some of these applications over the last decade. These systems were effective but provided 
more functionality than required and as such had limited application. For most machine 
applications, the requirements were very simple: shut down if a single failure is detected, 
prevent subsequent operation until the failure has been corrected. This requirement, known as 
Control Reliable is quickly gaining acceptance, in North America. In Europe first DIN 
19250[4] and then the IEC 61508[5] standards are leading the way for defining the safety of 
electronic systems with similar requirements and will likely emerge as having worldwide 
acceptance. 


Meanwhile a safety bus committee was formed in Germany in 1989 to define the requirements 
for using standard communications networks for safety applications [1]. Their initial goal was 
to provide a guide to apply IEC 61508 to communication networks. Their long-term goal is for 
this work to become part of the IEC 61508 standard. Their work is targeted primarily at high 
integrity (Safety Integrity Level 3) safety shutdown systems using single media on standard 
networks. 


The approach the committee has recommended is to start with a standard, presumed unreliable, 
communication network and add a safety layer in the communications stack to ensure that any 
errors in message transmission are detected. They have based their requirements on the railway 
standard pr EN 50159-1[2]. This standard lists various errors that can occur and requires that at 
least one measure be in place to detect each of these errors. If an error is detected a safety 
action is taken. This means that it is possible to perform a safety function across a standard 
communications network by adding a safety layer that includes safety measures such as time 
stamps, receiver identification, CRC, time gated transmission and redundant communications. 
Volume 5 of CIP common defines the safety protocol using these measures and demonstrates 
how the common portions of this protocol can be applied to DeviceNet. 


Chapter 2 presents the general case for the safety communication layer. 
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1-3.1 


Requirement Conventions 


This specification uses 3 ways to identify requirements based on the type of requirement; 


1. Functional Requirement Scope — Functional requirements are those requirements that are 
related to device functionality. These requirements have safety significance and are 
traceable to a conformance test, white-box test, or Safety Manual checklist. These 
requirements are identified by the numbered tag FRSxxx, where xxx is a unique number 
assigned to the requirement for traceability. 

2. System Requirement Scope — System requirements are those requirements that are related 
to the safety system in which a safety device would be used. These requirements have 
safety significance and are traceable to a conformance test, white-box test, or Safety 
Manual checklist. These requirements are identified by a numbered tag SRSxxx, where 
Xxx is a unique number assigned to the requirement for traceability. 

3. Interoperability requirements — These are requirements that carry no safety significance 
and are not required to be traceable to a test. These requirements are identified by 
untagged textual statements containing the word “shall”. 


Definitions & Acronyms 


This section describes the definitions and acronyms in the context of this document. 


Definitions 
Term Definition 
Adapter Device A device that is the server or target side of a network connection. These 
devices cannot originate any requests. 
Bridge an abstract device that connects multiple network segments along the data link 
layer 
Connection A persistent communications path between two devices 


DeviceNet Safety 


An implementation of a safety protocol on standard DeviceNet. 


Failure 


The termination of the ability of a functional unit to perform a required 
function 


Dangerous Failure 


A failure which has the potential to put the safety-related system in a 
hazardous or fail-to-function state 


Hamming Distance 


The number of individual bit errors in a message before an undetected error 
can occur in a message. 


Extended Format 


Abbreviated as EF. Format used for connection RPIs greater than 100ms or 
for applications where there is a need to avoid dropped connections. 


Messaging Errors: 
Repeated message 
Lost message 
Inserted message 


Re-sequenced message 


Corrupted message 
Delayed message 


Coupling of information 


A type of mes 


age error in which a single message is received more than once. 
A type of message error in which a message is removed from the message 


stream. 


A type of message error in which an additional message is implanted in the 
message stream. 

A type of message error in which the order of messages in the message stream 
is changed. 

A type of message error in which a data corruption occurs. 

A type of message error in which a message is received at a time later than 
intended. 

A type of inserted message in which a non-authentic message is designed to 


appear to be authentic. This may be the coupling of safety messages or the 
coupling of standard and safety messages. 
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Term 


Definition 


Multi-Cast 


A connection between several devices where one device produces data that is 
consumed by one or more devices. 


Network Time Expectation 


The worst-case time, from a safety related event occurring as input to a Safety 
Producer or as a fault within the Safety Producer until the output of the Safety 
Consumer is put into the safety state. 


Off-link Connection 


A connection between two or more devices that are on physically different 
networks. 


Base Format 


Original Safety packet format for RPI’s less then 100ms. 


Originator 


A node that requests the creation of a connection 


Ping 


The sequence of messages that coordinates time between consumers and. 
producers 


Ping Request 


Request for the acknowledge of the reception of a message. 


Ping Response 


Response to a ping request. 


Safety Application 


User related programs designed in accordance with IEC 61508 to meet the SIL 
requirements of the application 


Safety Chain 


A complete end-to-end safety function made up of sensors, inputs, control 
functions, outputs, and actuators. 


Safety Communication 
Channel 


A communications connection that implements the safety protocol 


Safety component 


A device or part of a device that is designed in accordance with IEC 61508 that 
meets the desired SIL level for the application 


Safety Connection 


A connection that utilizes the safety protocol for communications transactions. 


Safety Controller 


A device designed in accordance with IEC 61508 that executes a user defined 
safety function 


Safety Data 


Data that is transmitted across a safety network using a safety protocol. This 
data meets SIL 3 integrity level. 


Safety Device 


Device that contain the safety protocol. 


Safety Layer 


A layer of functionality in the communications stack that provides the safety 
protections for safety messaging 


Safety Network (Bus) 


An implementation of a safety protocol. 


Safety Originator 


A device that originates safety connections 


Safety Protocol 


An additional communication layer, on a standard protocol that is used to 
provide high integrity communications transactions. 


Safety Time 


The worst-case response time from physical input to physical output. This 
time also accounts for an error in the control system (e.g., watchdog timeout). 


Safety Validator 


The Safety Validator Object contains the implementation of the safety protocol 
on a safety device. 


Safety Validator Client 


a instance of a that accesses a (remote) service 


Safety Validator Server 


A computer software application that carries out some task on behalf of users 


Scanner Device 


A device that is the client or originating side of a connection. Scanner devices 
typically have adapter functionality as well. 


Signature A method of uniquely identifying a set of data. This could be by revision, 
checksum or some other method that is agreed upon by the originating and 
target devices. 

Single-Cast A connection between a single originator and target device. 


Standard Component 


Devices or portions of devices that do not participate in the safety function. 


Target 


A node that receives a 


connection creation request 
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1-3.2 Acronyms 
Term Definition 

loo2 One out of two safety architecture 

BER Bit Error Rate 

BIA Berufsgenossenschaftliches Institut fiir Arbeitsschutz - BIA, The BIA is an institute for 
research and testing of the German Berufsgenossenschaften (BG), the institutions for statutory 
accident insurance and prevention in Germany 

CFUNID Configuration Owning UNID 

CIP Acronym for Common Industrial Protocol. This is the application framework shared among 
DeviceNet, ControlNet, and Ethernet/IP. 

CPCRC Connection Parameters CRC 

CR: Connection Point 

CPU Central Processing Unit 

CRC Cyclical Redundancy Check — A number derived from, and stored or transmitted with, a block 
of data in order to detect corruption. 

CRC-Sx Notation for use of Safety Related CRC-S1, CRC-S2 CRC-S3 or CRC-S4 

DUT Device Under Test 

EDS Device Net specific Electronic data sheet 

EPATH A data type, based upon the Abstract Syntax Notation (ASN.1), used to describe connection 
paths, data types, certain configuration data, etc 

EPI Expected Packet Interval 

F-PLC Failsafe programmable logical controller 

EF Extended Format. Format used for connection RPIs greater than 100ms or for applications 
where there is a need to avoid dropped connections. 

MACID Media Access Identifier — For purposes of this specification, MACID is defined as follows: For 
DeviceNet safety devices, this is the node address of the device on the network. For 
EtherNet/IP safety devices, this is the IP address of the device on the network. 

NID Network Identifier 

NTE Network Time Expectation 

NV Non Volatile 

NVS Non Volatile Storage 

OcP Output Connection Point 

OCPUNID Output Connection Point Owning UNID 

ODVA Open DeviceNet Vendor association 

OUNID Originator Unique Network Identifier 

PFD Probability of failure on demand 

PFH Probability of dangerous failure per hour 

PID Unique Producer ID 

PLC Programmable Logical Controller 

RBD Reliability Block Diagram 

SCCV Safety Configuration Consistency Value 

SCTS Safety Configuration Time Stamp 

SIL Safety Integrity Level 

SNCT Safety Network Configuration Tool 
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Term Definition 
SNN Safety Network Number 
SNIL Safety Network Interface Layer. The SNIL is the safety network protocol firmware, media 


dependent communication layer firmware, and required communication interface hardware 
(including communication processors). 


SPTE Safety Protocol Test Engine 
TBD To Be Determined 
TSCCV Targets Safety Configuration Consistency Value 
TUNID Target Unique Network Identifier 
TUV “Technischer Uberwachungsverein” — German certification and consulting organization 
UCMM Unconnected Message Manager 
UNID Unique Network Identifier 
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2-1 Safety Protocol Overview 
The safety network is designed as a protocol independent safety layer that resides above the 
existing network or backplane protocol. The entity-relationship shown in Figure 2-1.1 shows 
the relationship between possible devices, networks and components. 


Figure 2-1.1 Entity Relationship Diagram of Target Safety System 


Safety has tine Safety has 1:1 » Network 
Device Channel 
—has 1 alll 1 ris - Ai 
v | 
Safety Validator, Safety Validator Serial 
Client Server ene} 
is-a 
is -a— is -a 
SERCOS III DeviceNet EtherNet/IP 
is is Is Is 
Monitor Controller VO Module VO Device 
has 0:1—-has 0:15 
' } 
has 1:1 has 1:1 hastn Sensor Actuator 
T 
‘has 1:n- 
Safety Saf ty Physical 
fet : fel : ysical 
or hee On - Component mone oa V/O Point 

has 1:n 

Safety 

Chain 


In Figure 2-1.1, safety devices are controllers, monitors, I/O modules or I/O devices. I/O 
devices may be one of two types, sensor and actuator. Controllers and monitors originate 
communications with devices. I/O devices, I/O modules, monitors and controllers are all types 
of devices. Safety devices can have one or more safety communication channels, each of 
which can be connected to a single network. Each safety channel has a Safety Validator Client 
and a Safety Validator Server. 
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2-1.1 


2-1.2 


The entity relationship diagram in Figure 2-1.1 shows an entire safety application residing in a 
single controller or monitor. A safety application can contain multiple safety components that, 
in turn, can contain other safety components. A safety application will contain one or more 
safety chains. Much like the safety application, the safety chain can contain multiple safety 
components that, in turn, can contain other safety components. The resulting structure for a 
safety application is, therefore, a tree of safety components, with each having access the I/O 
points within the safety system. 


Design Approach 


The CIP Safety approach uses the safety processes and coding recommendations of the German 
Safety Bus committee, as documented in the German Safety Bus Committee Specification, 
Appendix A. that relies on providing measures for possible transmission errors as initially 
defined in ISO-62280-1. This specification requires a single measure to detect each error 
condition. The CIP Safety approach exceeds these basic requirements and provides alternate 
detection measures where possible. Table 2-1.1, is based on the Error and Measures table 
documented by the German Safety Bus Committee. Table 2-1.1 shows just those measures that 
the safety protocol uses to detect errors. Also provided in the table are references within this 
specification where the detection measures are fully described; thus, this table can be used as 
the central starting point in analyzing the safety protocol. 


Communication Errors and Measures to Detect Errors 


Table 2-1.1 Measures Against Errors in Messages 


Measures to detect communications errors 
Time Identification | CRC | Redundancy Different data 
Communication Errors Expectation | for sender and with Cross integrity assurance 
via time receiver Checking | systems for safety and 
stamp standard messages 
Message Repetition 2-1.2.1 x x? 
Message Loss 2-1.2.2 x x? 
Message Insertion 2-1.2.3 x x x 
Incorrect Sequence 2-1.2.4 x x 
Message Corruption 2-1.2.5 x x 
Message Delay 2-1.2.6 x 
Coupling of safety and safety Xx 
information 2-1.2.7 
Coupling of safety and x x x x x 
standard information 2-1.2.8 
Increased age of data in x 
bridge ' 2-1.2.9 


1. This requirement is not part of the German Safety Bus Committee Specification 


2. The Safety CRC provides additional protection for communication errors in fragmented messages. 
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2-1.2.1 


2-1.2.2 


2-1.2.3 


2-1.2.4 


2-1.2.5 


Message Repetition 


It is possible for a message to be repeated on a network. This in itself does not represent an 
error, because the safety protocol allows overwriting of data. However, a repeated message 
will not have an updated time stamp, because only the base producer can update the time 
stamp. Repeated messages that were received in place of new data may result in the 
connection’s termination (2-1.3.2) if they did not meet the consumer’s time expectation. 


Message Loss 


Time Expectation detects loss of a message. FRS3 The safety protocol requires messages to 
occur within defined time expectations. Messages received later than these time expectations 
shall be treated as errors, resulting in the connection's termination. 


Message Insertion 
Message insertion is detected by two measures: 


Time Expectation: An inserted message will result in a connection termination because the 
message received will have an unexpected value in its time-stamp or time-stamp/roll-over 
count. 


An inserted message is detected by identification of sender and receiver. A unique identifier is 
encoded with the CRC-Sx of the time stamp section, time coordination section, and both of the 
data sections (2-1.7.1). If the CRC-Sx is incorrect, either the data is corrupted or a message has 
been sent to the wrong device. See FRSS (Section 2-1.2.5) to see how this error is handled.. 


Incorrect Sequence 


The time expectation detects an incorrect sequence. The incorrect sequence of a message will 
result in a connection termination because the message received has an unexpected value in its 
time-stamp and/or roll-over count. 


Message Corruption 


Two additional measures of safety networks exceed the native measures of standard networks 
to detect message corruption: 


Cyclic Redundancy Check: A safety cyclic redundancy code, CRC-Sx (2-1.7.2), is encoded in 
each safety message. 


FRSS A message corruption shall be detected when the data and CRC-Sx are calculated and 
compared. This error shall cause the connection to be 

Terminated 

IF (Base format) OR (Extended Format AND Consumer_Fault_Count) >= Max_Fault_Number 
OR Dropped 

IF Extended Format AND Consumer_Fault_Count < Max_Fault_Number. 
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2-1.2.6 


2-1.2.7 


2-1.2.8 


2-1.2.9 


Redundancy with cross checking: All safety data is sent twice (one copy is the ones 
complement) in the same message packet. The received safety data is crosschecked when it 
arrives at the consumer. FRS6 A corrupted message that was not detected by the link or CRC- 
Sx check (i.e., error that exceeded the Hamming distance of CRC) shall be detected when the 
actual and complemented copies of the data are compared in the consumer. See Section 2-1.8 
for details. 


Message Delay 


Time Expectation detects message delay. If an expected message is not received at the 
consumer during the required time interval, the connection’s periodic timer will expire and the 
connection shall be terminated (2-1.3.2) See Section 2-7 for a detailed description of safety 
network times. 


Coupling of Safety and Safety Information 


The coupling of safety messages is detected by the inclusion of a unique identifier, called the 
PID in the time stamp section, data sections and time correction message Safety CRC 
calculations. It is called the CID in the time coordination message Safety CRC calculations (2- 
1.7.1). The PID and CID are established at connection time and is not transmitted with the 
data. FRS7 The PID or CID is incorporated within the Safety CRC calculation in both the 
producer and the consumer, thus, if a message is mistakenly received, it shall be detected when 
the CRC is checked. 


Coupling of Safety and Standard Information 


All five of the safety detection measures are designed to detect the coupling of safety and 
standard information because a standard message will not use the safety format. FRS8 Safety 
consumer shall detect standard messages as an incorrectly formed message. 


1. Redundancy with cross check: Any standard message that was inadvertently received by a 
safety consumer will not meet the requirement for redundant data in the same link packet 
and therefore an error will occur when cross checking is attempted, See Section 2-1.8. 

2. Different data integrity assurance systems for safety and standard devices: Safety messages 
have a unique message encoding (2-1.7), which includes a time stamp and a unique Safety 
CRC-Sx. A standard device connection will not be able to encode information in this 
format or generate the correct cyclic redundancy code of a safety message. 

3. A standard message will not contain the Safety CRC (as generated by the Safety CRC 
algorithm) and will not construct the message using the correct safety format, thus a 
standard message will be detected as an error condition. 

4. A standard message will not contain a correct timestamp; this shall cause an error to be 
detected. 

5. A standard message will not contain the correct packet format; this shall cause an error to 
be detected. 


Increased Age of Data in Bridges 


A time stamp using time expectation is used to detect possible increased age of data in bridges. 
If an expected message is not received at the consumer by the required time interval, the 
connection will be terminated (2-1.3.2). See Section (2-1.8.1) for a detail explanation of the 
time stamp protocol. 
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2-1.2.10 


2-1.2.10.1 


2-1.2.10.2 


2-1.2.11 


2-1.3 


2-1.3.1 


2-1.3.2 


Addressing errors 


This section describes the measures used to detect addressing errors. 


Producer generates an incorrect address, changes header 

1. A message is somehow misdirected to an invalid address. This condition detected by: 
Message Loss (2-1.2.2) in the original consumer. 

2. A Message is somehow misdirected to another safety device, This condition is detected 
by: Message Insertion (2-1.2.3), Repetition (2-1.2.1), Incorrect Time Stamp (2-1.2.4), 
Message Delay (2-1.2.6), and, Coupling of Safety and Safety Information (2-1.2.7). 


Consumer consumes a wrong address 

1. A safety device consumes a message intended for another non-safety related device. This 
condition is detected by Coupling of Safety and Standard Information (2-1.2.8). 

2. Asafety device consumes a message intended for another safety device. This condition is 
detected by: Message Insertion (2-1.2.3), Message Repetition (2-1.2.1), Identification for 
receiver, and Incorrect Time Stamp (2-1.2.4), and, Coupling of Safety and Safety 
Information (2-1.2.7). 


Measures to Protect Standard Devices from Safety Devices 


Safety devices are built on the standard network protocol and do not impact standard devices 
other than using available bandwidth. Improper allocation of bandwidth may cause nuisance 
trips to the safety system, causing it to go to a safety state. See section (2-1.8.1). 


Communication Protocol Behavior 


Sequence of Safety Checks 


FRS9 The following Sequence of checks shall be used to check messages: 


e Ping count check 

e Evaluate Time stamp section CRC 

e Evaluated Time Stamps 

e Evaluate Actual Data CRC 
Evaluate Complement Data CRC 

e Perform Cross-Check 


Connection Termination 


FRS10 When a producer detects an error that requires connection termination it shall terminate 
the connection, and notify the application of the action. 


FRS11 All consumers shall monitor the periodic transmission of data and go to a safety state if 
the periodic transmissions cease. _ If the consumer detects an error, it must go to a safety state 
and terminate the consuming connection associated with that error. 


FRS12 When the Safety Layer detects an error requiring connection termination the 
termination shall be implemented using the following sequence. 
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2-1.3.3 


2-1.4 


e The safety layer detects an error requiring termination 

e The safety layer notifies the application program by setting the connection status to indicate 
a safety communications fault 

e The safety application shall transition data and I/O (e.g. set outputs to the safety state) 
associated with the connection to a safety state 

e The safety layer shall notify the underlying communications system of an error and request 
the termination of the connection by setting its status to indicate a safety communications 
error 

e The safety layer shall not transition from its safety state until the fault is cleared and a 
connection restart sequence is initiated. 


Cross Checking Error 


FRS13 When crosschecked safety data are found to be different, the data is treated as faulty. 
The base format consumer shall terminate the connection (See Section 2-1.3.2) and the 
Extended Format consumer will increment the Consumer_Fault_Count and drop the packet if 
the count is less than the Max_Fault_Number, or terminate the connection if is equal to or 
greater than the Max_Fault_Number. 


Communication Layers 


The safety protocol is layered on top of the standard network protocol. 


The Safety Layers accept safety data from the safety application circuit. The safety layers then 
‘ormulate a safety message, transmit the safety message, receive and decode the safety 
message. Once the safety message is decoded and verified, the data is presented to the 


receiving safety application circuit 
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Figure 2-1.2 Communication Layers 
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2-1.5.1 Logical 
The logical information flow is identical for both systems, as shown in Figure 2-1.3. This flow 
consists of the gathering of safety information at the safety input, then a safety transmission of 
this information to the controller. The safety information is processed and the resulting safety 
information is transmitted to the safety output, where the safety action takes place. 
Figure 2-1.3 Logical information flow! 
Detect | — Process —— Apply 
Safety Transmission Safety Transmission ) 
Safety Data i Safety Data ss Safety Data 
2-1.5.1.1 Addresses for Safety Devices 


FRS14 Each safety device shall have a single physical address that is unique on the device’s 
network segment. 


"Note: All safety subsystems shall meet the requirements for the desired Safety Integrity Level 
(SIL) for the application 
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2-1.5.2 


2-1.6 


2-1.6.1 


2-1.6.2 


Physical Topologies 


FRS15 The safety network shall not restrict any physical topologies. 


Supported Safety Connections 
There are two types of safety connections defined for the safety protocol: 


e Single-Cast 
© Multi-Cast 


Single-Cast Safety Connections 


FRS 16 For single-cast safety connections, the Single-cast Safety ValidatorClient shall produce 
safety data to the Single-cast Safety ValidatorServer as defined by the Expected Packet Interval 
(EPI) rate. 


FRS17 The Single-cast Safety ValidatorServer shall respond to a ping request and produces an 
Time Coordination message with a Time_Value to the Single-cast Safety ValidatorClient that is 
used by the safety data producer. 


FRS18 The Single-cast safety data producer shall use the time value returned in the ping 
response (Time Coordination message) to adjust the time stamp sent the Single-cast produced 
data. The time stamp is relative to the safety data consumer’s clock. 


Figure 2-1.4 Single-Cast Block Diagram 
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In the diagram above, the safety critical processing is performed within the shaded areas. A 
single-cast safety connection will require two transport connections. 


Multi-Cast Safety Connections 


FRS23 For multi-cast safety connections the Safety ValidatorClient shall produce Safety Data 
to multiple (n = 2 to 15) Safety ValidatorServers as defined by the Expected Packet Interval 
(EPI) rate. 


FRS24 The produced Multi-Cast safety data shall include a Producer_Time_Stamp with each 
safety data production. 


FRS25 The Multi-Cast Safety ValidatorServers shall respond to a ping request by sending an 
Time Coordination message with a Consumer_Time_Value to the Safety ValidatorClient. 
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FRS26 The Multi-cast Consumer_Time_Values shall be used by the Multi-cast safety data 
producer to generate a Time_Correction_Value for each safety data consumer . 


FRS27 A Time_Correction_Value shall be sent by the Multi-cast safety data producer to each 
safety data consumers each Ping Interval. 


FRS28 The Multi-cast safety data consumer shall use the Producer_Time_Stamp and the 
Time_Correction_Value to derive a Data_Time_Stamp that is relative to the safety data 
consumer’s clock. 


The Time_Correction_Value is sent to each consumer in one of 2 ways. 


FRS29 For devices on a DeviceNet network, the Multi-cast Time_Correction_Value shall be 
sent to the consumers via a separate multi-cast trasport connection. 


Figure 2-1.5 Multi-Cast Block Diagram - DeviceNet 
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FRS30 For devices on a non-DeviceNet network, the data and Time_Correction_Value shall be 
concatenated and sent to the consumers via a single multi-cast transport connection. 
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Figure 2-1.6 Multi-Cast Block Diagram, non-DeviceNet 
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Tn the diagram above the safety critical processing is done within the shaded areas. A multi- 
cast safety connection shall require 3 times n transport connections for DeviceNet devices, and 
2 times n transport connections for non-DeviceNet devices.. 


2-1.7 Safety Transmission Protocol 


FRS32 All safety messages and safety response messages shall be encoded with the safety 
CRC’s defined in Appendix E . 


2-1.7.1 Safety Message Encoding 


The Safety Protocol defines nine section encoding formats that are used in different 
combinations for safety messaging. 


¢ Base format | or 2 byte Data Section (See section 2-1.7.1.2) 

e Extended format 1 or 2 byte Date Section (See section 2-1.7.1.4) 

e Base format 3 to 250 byte Data Section (See section 2-1.7.1.5) 

e Extended format 3 to 250 byte Data Section (See section 2-1.7.1.6) 
e Base format Time Stamp Section (See section 2-1.7.1.7) 

e Base format Time Coordination Section (See section 2-1.7.1.8) 

e Extended format Time Coordination Section (See section 2-1.7.1.8) 
e Base format Time Correction Section (See section 2-1.7.1.8.2) 

e Extended format Time Correction Section (See section 2-1.7.1.8.2) 


These section encodings are used to construct six safety message types. In all six types, they 
can use either the Base format or the Extended format. 
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The six types of safety message are: 


e 1 or 2 byte Single-Cast (See section 2-1.7.1.9) 

1 or 2 byte Multi-Cast DeviceNet (See section 2-1.7.1.10) 

1 or 2 byte Multi-Cast Non-DeviceNet (See section 2-1.7.1.11) 

3 to 250 byte Single-Cast (See section 2-1.7.1.12) 

3 to 250 byte Multi-Cast DeviceNet (See section 2-1.7.1.13) 

3 to 248 byte Multi-Cast Non-DeviceNet (See section 2-1.7.1.14) 


The following table shows which Sections are used within the various message types: 


Table 2-1.2 Connection Sections and Message Types 


Time Time 
Safety Connection Format Data Message” Coordination Correction 
Message” Message” 
g ge | €| - 5 5 
> = 3 & 2 3 
a Pt 3 2/8 3 3 
5 g 2) ls 3 a 
g = ad g g 3/3 a g 
S = = 5 & 3 2 § eg s 
aA 2 s28 Gy 3 ale & 2s 3 
Ss g ES & te 2 Els 5 =o P 
3 = se g = a |O 8 ae 2 
a 5 Zz = ay ale aI 5 
iS) a Ss 
xe nN e 2 | z ro) 
$ a E/E iS 2 
3 b a = S zg 
‘a = s a 1S) = 
a eal a =I 
lor2 Single-Cast | All x x? x 
bytes DeviceNet x x x X 
Multi-cast | Non- i 
DeviceNet - a x x 
3 to 250 | Single-cast | All x x! x 
Bytes 
3 to 248 | Multi-cast DeviceNet x x! x x 
Byles Multi-cast Non: 
i x 1 
DeviceNet zl stall es is 


1 Base format has independent section for Time Stamp; it is part of the data section in the Extended format 


2 Message can use either Base or Extended format. 


Originators and Targets shall follow selection criteria shown in Table 2-1.3 for the usage of the 
Base and Extended Formats. 


Table 2-1.3 Connection Sections and Message Formats 


Type Base Format Extended Format 
Originator Required! Required 
Target Required! Required 


' May be optional in future editions. 
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2-1.7.1.1 Mode Byte 


The Mode Byte is described outside of the section definitions because various parts are 
included in the various section CRCs. In the base format, bits 0 thru 4 of the mode byte are 
part of the time stamp section, while bits 5 thru 7 are part of the data sections. In the short 
packet Extended Format, bits 5 thru 7 are part of the data CRC. In the large packet Extended 
Format bits 0 thru 4 of the mode byte are part of the complement data CRC, while bits 5 thru 7 
are part of the true data CRC. The variables used in the mode byte, brief descriptions and 
references to complete descriptions are given in Table 2-1.4. 


Figure 2-1.7 Format of the Mode Byte 


Mode Byte 
7 6 5 4 3 2 1 Oo 
Run_Idle TBD_2 Bit TBD Bit 


NRun Idle TBD.2 Bit Copy, N_TBD Bit Ping Count 
N_Run_Idie* N_TBD_2 Bit* N_TBD_Bit* 


* These values are not sent in the data packet, they are derived by the consumer 


Table 2-1.4 Mode Byte Variables 


Name Description Reference 
Run_Idle FRS34 Run_Idle shall be used to indicated the 2-4.1.1 
usability of the data as determined by the Producer 
Safety Application 
N_Run_Idle Complement of the Run_Idle 2-4.1.2 
TBD_2_Bit Reserved for future use 2-4.1.3 
TBD_2_Bit Copy of the TBD_2_Bit 2-4.1.4 
Copy 
TBD_Bit Reserved for future use FRS126 The TBD_Bit Shall 2-4.1.6 
be set to 0 by the Safety Validator 
N_TBD_Bit Complement of the TBD_Bit 2-4.1.7 
Ping_Count The ping count is used for determining when a 2-4.1.5 
consumer should send a time coordination message 


2-1.7.1.1.1 Mode Byte CRC Processing for Base Format 


FRS37 The Mode Byte processing within the Base Format CRCs shall be done as shown as 
follows. 


¢ CRC Type Mode Byte logic prior to inclusion within the CRC 


e Actual Data CRC Mode Byte AND O0xE0O 
¢ Complement Data CRC (Mode Byte XOR 0xFF) AND 0xE0 
¢ Time Stamp Section CRC Mode Byte AND Ox1F 


2-1.7.1.2 1 or 2 Byte Data section, Base Format 


FRS38 The | or 2 Byte Data section for the base format shall consist of the actual data byte or 
bytes, the mode byte, the actual CRC, and the complement CRC. 


~2-15— 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 2: Safety Protocol Requirements 


Figure 2-1.8 1 or 2 Byte Data Section Base Format 


1 or 2 Byte Data Section, Base Format 


Actual Data 


Mode Byte 


Actual CRC 


FRS39 The Base format | or 2 Byte Actual Data CRC calculation shall include: 
e Producer Identifier (PID) (by CRC-S/) 


© The (Mode Byte) AND (0xE0) (by CRC-S/) 
© Actual Data byte(s) (by CRC-S1) (see yellow colored sections) 


FRS40 The Base Format | or 2 Byte Complement Data CRC calculation shall include: 
e Producer Identifier (PID) (by CRC-S1) 


e The (Mode Byte XOR 0xFF) AND (0xE0) (by CRC-S2) 
© Actual Data bytes XOR OxFF (by CRC-S2) (see QIBBM colored sections) 


Note that the PID uses CRC-S1 for both the actual and the complement CRC calculation. 


Refer to Appendix E for code samp! 


ies. 


2-1.7.1.3 Calculation order for Extended Format CRC calculations 
Figure 2-1.9 below shows where the rollover count fits into the CRC calculations for the 
Extended Format messages. Note the CRC seed is still based on the PID/CID as in the base 
format; the Rollover count is treated as an additional data parameter. 
Figure 2-1.9 CRC Calculation order for Extended Format messages 
PID seeds Rollover_Count Runtime Data 
additions to CRC included in CRCs 
calculation 
cr = ———= 
Byte PIO Rolover Count] Made. Byte + Tine simp | ——! [RRESST) 
Format 
3 to 250 PID "Rolover Count] = eee | +b) Actual bata > Ee 
Byte 
Format PID Rollover count | Mage Byte | 4. | Complement 4. | Time Stamp S | oRCSS 
Time. Time NN 
coutenass PID +) ack aye og sime > | orcs 
orm [0 +| ae + ee ross 
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2-1.7.1.4 


1 or 2 Byte Data Section, Extended Format 


FRS365 The | or 2 Byte Data section for the Extended format shall consist of the actual data 
byte or bytes, the mode byte, the time stamp, and CRC-SS5 calculated over the entire packet. 


Figure 2-1.10 1 or 2 Byte Data Section, Extended Format 


Actual Data | Mode Byte’ 


1 - 2 Byte Data Section, Extended Format 
t CRC $5 Time Stamp | _CRC $5 


' Bits 4-0 are not included in the CRC calculation. 


2 bytes 1 byte 2 bytes 2 bytes 1 byte 


2-1.7.1.5 


FRS366 The Extended 1 or 2 Byte Data CRC calculation shall use CRC-S5 and include: 


e Producer Identifier (PID) 

e 16-bit Rollover count 

¢ Mode Byte & OxEO 

e Actual Data byte(s) 

e Time Stamp (see yellow colored sections) 


Refer to Appendix E for code samples. 


3 to 250 Byte Data section, Base Format 


FRS41 The Base format 3 to 250 Byte Data section shall consist of the actual data bytes, the 
mode byte, the actual CRC, the complement data bytes, and the complement CRC. 


Figure 2-1.11 3 to 250 Byte Data Section, Base Format 


3 - 250 Byte Data Section, Base Format 
Actual Data Mode Byte Actual CRC Complemented Data Comp. CRC 
3- 250 bytes 1 byte 2 bytes 3- 250 bytes 2 bytes 


FRS42 The Base format 3-to250 Byte Actual Data CRC calculation shall include: 
e Producer Identifier (PID) (by CRC-S3) 


e The (Mode Byte) AND (OxE0) (by CRC-S3) 
e Actual Data byte(s) (by CRC-S3) (see yellow colored sections) 


FRS43 The Base format 3-to250 Byte Complement Data CRC calculation shall include: 


e Producer Identifier (PID) (by CRC-S3) 
e The (Mode Byte XOR 0xFF) AND (0xE0) (by CRC-S3) 
« Complemented Data bytes (by CRC-S3) (see green colored sections) 


Refer to Appendix E for code samples. 
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2-1.7.1.6 3 to 250 Byte Data section, Extended Format 


FRS367 The Extended 3 to 250 Byte Data section shall consist of the actual data bytes, the 
mode byte, CRC-S3, the complement data bytes, the time stamp and CRC-SS . 


Figure 2-1.12 3 to 250 Byte Data Section, Extended Format 


3-250 Byte Extended Format 


Actual | Mode Byte | Actual Data Complement Time Compl. Data 
Data crc Data Complement Data CRC Stamp CRC 
3-250 bytes 1 byte 2 bytes 3 — 250 bytes 2 bytes 2 bytes 1 byte 


FRS368 The Extended format 3-to250 Byte Actual Data CRC calculation shall include: 


e Producer Identifier (PID) (by CRC-S3) 

e Rollover Count (by CRC-S3) 

The (Mode Byte) AND (OxE0) (by CRC-S3) 

e Actual Data byte(s) (by CRC-S3) (see yellow colored sections) 


FRS369 The Extended format 3-to250 Byte Complement Data CRC calculation shall include: 


e Producer Identifier (PID) (by CRC-S5) 

e¢ Rollover Count (by CRC-S5) 

© Mode Byte AND Ox1F (by CRC-S5) 

e Complemented Data bytes (by CRC-S5) 

e Time Stamp (by CRC-S5) (see green colored sections) 


Refer to Appendix E for code samples. 


2-1.7.1.7 Time Stamp Section, Base Format 


The Base format Time Stamp section is composed of bits 0-4 of the mode byte, the 
Time_Stamp, and the time stamp CRC. 


Figure 2-1.13 - Base Format, Time Stamp Section Format 


Data 
Section 


Table 2-1.5 Time Stamp Variables 


Time Stamp Section 


Mode Byte 


Name Description Reference 


Data_Time_Stamp | Single-Cast -- Data_Time_Stamp is the time the data was 2-4.2.1 
sampled for production relative to the consumers clock 
Multi-Cast -- Data_Time_Stamp is the time the data was 
sampled for production relative to the producers clock 
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2-1.7.1.8 


FRS45 The Base format Time Stamp CRC calculation shall include: 


e Producer Identifier byte (PID) (by CRC-S1) 
e The (Mode Byte) AND (0x1F) (by CRC-S1) 
e Time Stamp byte(s) (by CRC-S1) (see blue colored sections) 


Time Coordination Section 


FRS48 The time coordination section shall be sent from the consumer to the producer in 
response to a change in the ping count. 


The Time Coordination section is used as the Time Coordination Message for all single-cast 
and multi-cast time coordination requests. There are two formats: the base format and 
Extended format. 

The encoding for the time coordination section is shown in Figure 2-1,.14, The variables used 
in the time coordination section, brief descriptions and references to complete descriptions are 


given in Table 2-1.6. 


Figure 2-1.14 Base Format Time Coordination Message Encoding 


Ack_ Consumer_Tim Ack_ 
Byte _Value Byte 7 Jj cress | 


Ack Byte 
ra 5 4 3 2 4 0 
PE Reserved PR Reef PCR 


Parity_Even (of bits oe = Ping_Count_Reply 


Ping_Respons 


Figure 2-1.15 Extended Format Time Coordination Message Encoding 


Ack_Byte | Consumer_Time_Value CRC_S5_0 CRC_S5_1 CRC_S5_2 


Table 2-1.6 Time Coordination Message Variables 


Name Description Reference 
Consumer_Time_Value FRSS51 Consumer_Time_Value in the Time 2-4,3.2 
Coordination message shall (as closely as possible) 
mark the time at which the consumer sends a ping 
response message 


Ack_Byte Consisting of: 
Parity_Even FRS52 The Parity_Even bit in the Time Coordination 
message shall be even parity of bits 0 through 6 of the 
message 
Ping_Response_Bit FRSS53 The Ping_Response_Bit in the Time 2-4.3.1 


Coordination message shall indicates that a ping 
response is being sent 
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2-1.7.1.8.1 


2-1.7.1.8.2 


Name Description Reference 
Ping_Count_Reply FRS55 Ping_Count_Reply in the Time Coordination 2-4.3.3 
message shall indicates which ping request the 
consumer is responding to 


Reserved Reserved, set to zero 2-4.3.4 

CRC-S3 CRC covering the data within the Base Format time 
coordination message 

CRC-S5 CRC covering the data within the Extended Format 


time coordination message 


FRS56 The following rule shall be used for the calculation of the parity bit in the Time 
Coordination message: 


Bit 7 of the Ack_Byte form even parity on the Ack_Byte. 


FRSS7 The following rule shall be used for setting of the bits in Ack_Byte_2 of the Time 
Coordination message: 


Ack_Byte_2 = ((Ack_Byte XOR OxFF)AND 0x55)OR(Ack_Byte AND 0xAA) 


FRS370 When a connection is established with the Extended format, the EF Time Coordination 
format shall be used; otherwise the base format shall be used. 


Time Coordination CRC Calculation 
FRSS58 The Time Coordination CRC calculation shall include: 


e Consumer Identifier (CID) (by CRC-S3 or CRC-S5) 
e Ack Byte (by CRC-S3 or CRC-S5) 
e¢ Consumer_Time_Value (by CRC-S3 or CRC-S5) (see light grey colored sections) 


FRSS59 Ack_Byte_2 in the Base Time Coordination message shall not be included in the Safety 
CRC. 


Time Correction Section 


FRS60 The time correction message shall be sent from a multi-cast producer to each multi-cast 
consumer, once every ping interval. The time correction message, which contains consumer 
specific information, is sent by the producer to the consumer at a slower rate then the produced 
data. The encoding for the base time correction message is in Figure 2-1.16 and the encoding 
for the Extended format is in Figure 2-1.17. 
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Figure 2-1.16 Base Format Time Correction Message Encoding 


ia Mcast_ it Time_Correction_ Mcast_ 
Byte Value Byte_2 GINESS) 
Mcast_Byte 
7 6 5 4 3 ri | a fe] 
PE Reserved | MAI Reserved Consumer_# 
= Multi_Cast_Active_Idle 
Parity_Even (of bits 6:0) 
Figure 2-1.17 Extended Format Time Correction Message Encoding 
Time_Correction CRC-S5S_0 | CRC-S5_1 | CRC-S5_2 
Table 2-1.7 Time Correction Message Variables 
Name Description Reference 

Consumer_Time_Correction_Value FRS61 Consumer_Time_Correction_Value in 2-4.4.1 
the Time Correction message shall be used to 
correct the data time stamp and make the time 
relative to the multi-cast consumers clock. 

MCast_Byte Consisting of: 

Parity_Even FRS62 Parity_Even in the Time Correction 
message shall be the even parity of bits 0 
through 6 of the Message 

Multi_Cast_Active_Idle FRS358 Multi_Cast_Active_Idle in the Time 2-4.4.3 
Correction message shall indicate Idle if 
transmitted before this consumer has responded 
with a valid time coordination message ~ 

Consumer_# FRS65 The Consumer_# in the Time 2-4.4.1 
Correction message shall indicates the number 
of the consumer that this message is directed 
to. 

Reserved Reserved, set to zero 2-4.4.4 

CRC-S3 CRC covering the data within the Base Format 
time coordination message 

CRC-S5S CRC covering the data within the Extended 


Format time coordination message 


example code does not transmit Time Correction to a consumer until the initial Time Coordination 


is received 
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FRS66 The following rule shall be used for the calculation of the parity bit in the Time 
Correction message: 


Bit 7 of the MCast _Byte form even parity on the MCast _Byte. 


FRS67 The following rule shall be used for setting of the bits in Mcast_Byte_2 in the Time 
Correction message: 


MCast_Byte_2 = ((MCast_Byte XOR 0xFF)AND 0x55)OR(MCast_Byte AND 0xAA) 


FRS371 When a connection is established with the Extended format, the EF Time Correction 
format shall be used; otherwise the base format shall be used . 


2-1.7.1.8.3. Time Correction CRC Calculation 
FRS68 The Time Correction CRC calculation shall include: 


e Producer Identifier (PID) (by CRC-S3 or CRC-S5) 
e Mcast_Byte (by CRC-S3 or CRC-S5) 
e Time_Correction_Value (by CRC-S3 or CRC-S5) (see light grey colored sections) 


FRS69 MCast_Byte_2 of the Time Correction message shall not be included in the Safety 
CRC. 


2-1.7.1.9 1 or 2 Byte, Single-Cast, Safety Connection Format 


Figure 2-1.18 shows the section organization for | or 2 byte single-cast safety connection 
format. 


Figure 2-1.18 1 or 2 Byte Single-Cast Message Encoding 
Dase UI 
Extended 
Data-Eormat 


1-2 Byte Data Me: : 


Producer to Consumer 


we yj 
~- 
Base 1or2 byte Data Section Base Time Stamp Section 
Extended or Base 
Extended or 2 byte Data Time Coordination 
format Format 


Consumer to Product "i sans 
—aee Time Coordination Message 


2-1.7.1.10 1 or 2 Byte, Multi-Cast, DeviceNet Safety Connection Format 


Figure 2-1.19 shows the messages and section organization for the | or 2 byte Multi-cast Safety 
connections when the connections are on DeviceNet. 
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Figure 2-1.19 1 or 2 Byte Multi-Cast Message Encoding 


Base or Extended 
Data Format 


Producer to Consumer 


1-2 byte Data Message 


NN A w) 
~~ 


Base 1 or 2 byte Data Section Base Time Stamp Section 


Extended 1 or 2 byte Data 
format 
Extended or Base 
Time Correction Format 


Producer to Consumer 


Time Correction Message 


Extended or Base 
Time Coordination Format 


Consumer to Produc 5 tere 
Time Coordination Message 
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2-1.7.1.11 1 or 2 Byte, Multi-Cast, Non-DeviceNet, Safety Connection Format 


Figure 2-1.20 - shows the section organization for | or 2 byte multi-cast safety connections 
when the connections are on EtherNet/IP and other Non-DeviceNet networks in general. 


Figure 2-1.20 1 or 2 Byte, Multi-Cast, Safety Connection Format 


Base or Extended 
Data Format 


ee 


fo Producer to Consumes, ae 
1-2 Byte Data Message | Time Correction Message 
A v} 
na 
Base format 1-2 Byte Data Section Base Time Stamp Section Extended or Base 


Time Correction Format 


Extended Format 1-2 Byte Data 


Message Extended or Base 
Time Coordination Format 


Consumer to Produc . pepe 
Time Coordination Message 


2-1.7.1.12 3 to 250 Byte, Single-Cast, Safety Connection Format 


Figure 2-1.21 shows the section organization for 3 to 250 byte single-cast safety connection 
format. 


Figure 2-1.21 3 to 250 Byte Single-Cast Message Encoding 


Base or Extended 
Data Format 


3-250 Byte Data Message Producer to C onsumey, 


Base 3 to 250 byte Data Section Base Time Stamp Section 


Extended 3 to 250 byte Data format 


Base or Extended. 
Time Coordination Format 


Consumer to Producer| 


Time Coordination Message 
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2-1.7.1.13 3 to 248 Byte, Multi-Cast, DeviceNet Message Format 


Figure 2-1.22 shows the messages and section organization for 3 to 248 byte multi-cast safety 
connection format when the connections are on DeviceNet. 


Figure 2-1.22 3 to 248 Byte Multi-Cast Message Encoding 


Base or Extended 
Data Format 


3248 Byte Data Message Producer to Consumer, 
vi; 


\- 


Base 3 to 248 byte Data Section Base Time Stamp Section 


Extended 3 to 248 byte Data format 


Base or Extended 
Time Correction Format 


z =~ Producer to Consumer 
Time Correction Message 


Base or Extended 
Time Coordination Format 


Consumer to Producer] 3 —_ 
Time Coordination Message 


2-1.7.1.14 3 to 248 Byte, Multi-Cast, Non-DeviceNet, Safety Connection Format 
Figure 2-1.23 shows the messages and section organization for 3 to 248 byte multi-cast safety 


connection format when the connections are on EtherNet/IP or other Non-DeviceNet networks 
in general. 


Figure 2-1.23 3 to 248 Byte, Multi-Cast, Safety Connection Format 


Data Message 


Va 


Producer to Consumes = Sy 


3-248 Byte Data Message 


Time Correction Message 


A \y J 
Base format 3 - 248 Byte Data Section Base Time Stamp Section Base or Extended 
Time Correction Format 


Extended Format 3-248 Byte Data 
Format id Base or Extended 
Time Coordination Format 


Consumer to Produc z = 
Time Coordination Message 
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2-1.7.2 


2-1.8 


2-1.8.1 


Safety CRC 


There are five safety CRCs used in the various sections of the safety protocol. An 8-bit CRC 
(CRC-S1 or CRC-S2) is used for the base format data sections containing up to two bytes of 
safety data and the time stamp sections. A 16-bit CRC (CRC-S3) is used for base and EF data 
sections for 3 to 250 bytes of data and for the base format time correction and time 
coordination messages. A 24-bit CRC (CRC-SS) is used for the EF data format up to two bytes 
of safety data and for the EF complement data sections for 3 to 250 bytes of data. The 24-bit 
CRC is also used for the time correction and time coordination messages in Extended Format. 
A 32-bit CRC (CRC-S4) is used for connection establishment, configuration, and the Safety 
extension to the EDS file definition. 


Safety Procedures 


[he safety procedures provide a service that ensures data can be transmitted across a network 
ith a defined level of integrity. These procedures are defined as a safety protocol layer using 
a producer/consumer structure. All safety I/O transmissions across a network or bus will use 
this safety service. 


= 


[he usage of safety producers and safety consumers allows for consistency across all safety 
system topologies. 


Time Stamp Operation 


e time stamp allows for the calculation of the timeliness of receipt of data in the consumer. 
Figure 2-1.24 shows the time stamp sequence of operations for a simple single-cast producer 
consumer pair. 


Figure 2-1.24 Time Stamp Sequence 


Producer Consumer 


Count Count 
0 Time Stamp = 0, Ping =0 89 


Request a p>) 
92 92 


1 
2 

Newortset 3 ——. 93 
5 Response 94 
6 
7 


Offset = 92-587 95 
; 96 
: 97 
Timestamp = 8 Time Stamp = li 22 
8749=96 ee Max. age = 100-96 
1 
7 101 
is 102 
103 
13 104 
14 105 | Max. age = 108-103 
Timestamp = % Time Stamp = 103, Ping = 0 tae sd 
87+16=103 7 ees OG 
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2-1.8.2 


2-1.8.3 


2-1.8.3.1 


FRS70 Upon connection establishment, the producer shall request an initial ping response. 


FRS71 When the consumer sees a change in the ping count, the consumer shall prepare a Time 
Coordination response message that contains the consumer’s value of its clock count . 


FRS72 The producer shall use the clock count in the Time Coordination response to calculate 
an offset that will be applied to future productions. 


FRS73 At each scheduled production, the producer shall use the value of its own clock count 
and the offset to calculate the time stamp and sends it to the consumer along with the data. 


FRS74 The consumer shall use the value received from the producer to calculate the age of the 
data by subtracting the producers time stamp from its current clock count. If the calculated 
delta is less than the maximum delta specified by the user, the data is ok and the data is used by 
the application within the device. If the delta is greater than the user specified value, the data is 
deemed to be to old too use and the connection is terminated. 


FRS75 Once each Ping Interval, the producer shall request another ping response from the 
consumer. This will cause a recalculation of producer offset and prevent the slow aging of 
data due to time errors. 


A time correction factor is added to account for the maximum skew and drift of clocks in an 
asynchronous system. This message is used to adjust the offset in the producer. 


Rollover counts in the Extended Format 


A rollover count is employed in conjunction with the transmitted Time Stamp to extend the 
effective operating range of the Time Stamp to 32 bits. The Rollover count is not transmitted 
with the time stamp however. The initial values for the rollover count are set at connection 
establishment and maintained independently by both producer and consumer. The rollover 
count value is included in the data CRC calculation so both ends must agree on the current 
value at all times for packets to be received successfully. 


Protocol Sequence Diagrams 


The protocol sequence diagrams show the relationship between producers and consumers with 
respect to time and events. Time flows from the top of each figure to the bottom. Normal 
messages that are received at the producer or consumer are shown in normal text boxes. 
Anomalous messages are shown in bolded text boxes. Messages that were expected but not 
received are shown as unboxed text. 


Normal Safety Transmission 


Normal communication between a safety producer and consumer requires a sequence of 
periodic messages. When the consumer receives a valid message, the transaction is complete 
as shown in Figure 2-1.25. 
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Figure 2-1.25 Sequence Diagram of a Normal Producer/Consumer Safety Sequence 


Producer sar 
Saf 
‘afety Message (Data, Mode, Ping, Timestamp =1, CRC-S; ; 
t x) Valid = | 
Message | 
ey 
Es 
; Eg 2 
j 53 € 
zo <5 
sa ae 
52 
Safety 
ty Message (Data, Mode, Ping, Timestamp =1, CRC-S; : C , 
‘ x) Valid 


| Message } 


EPI 


Consumer Activity 
Monitor 


The safety producer produces data at a fixed rate called the Expected Packet Interval (EPI). 


FRS78 Link-triggered consumers shall maintain an activity timer, which is reset after receiving 
a valid expected message. 


FRS79 If a valid message has not been received before the activity timer expires, the link- 
triggered consumer shall terminate the connection (See 2-1.3.2) and go to the defined safety 
state. 


FRS80 All consumers shall check the age of the data received by checking the time stamps 
received. 


FRS81 If the age of the data is greater than the network time expectation the consumer shall 
terminate the connection (See 2-1.3.2) and go to the defined safety state. 
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2-1.8.3.2 


Figure 2-1.26 Sequence Diagram of a Normal Producer/Consumer Safety Sequence (production 
repeated) 


Producer Consumer Safety App. 


Safely Message (Data, 


1 Mode, Ping, Timestamp =1, CRC-Sx) = 
_, Message 
Used by 
Safely Message ye 
9¢ (Data, Mode, Ping, Timestamp =2, CRC-Sx) + 
Valid =3 
Message = 58 
Safety Messa : 
ge (Data, M : ; 
ode, Ping, Timestamp =3, CRC-Sx) fe a 
_| Valid Be 
ie Message | ES 
Safely Mesa, J Pa 
9¢ (Data, Mode, Ping, Timestamp =4, CRC-Sx) : = 
& Message 
Used by 
Safety Messay = 
9° (Data, Mode, Ping, Timestamp =5, CRC-Sx) dq . 
|. Valid a 
Message 8 
Safety Messa r “ 
ge (Data, M ° 
ode, Ping, Timestamp =6, CRC-Sx) Valid & ne 
alli 5 
“| Message | ES 
Safety Messa i 
9° (Pata, Mode, Ping, Timestamp =7, CRC-Sx) rs 
| Message 
Used by 
Consumer 


FRS82 Safety communications shall be configurable with production repeated. In this case, 
the consumer does not use every packet that is sent to it. 


FRS83 When safety communication is sent with repeated production, application-triggered 
consumers shall use the last packet received to complete the transaction. , as show in Figure 2- 
1.26 


FRS84 Consumers using base format connections shall see the Timestamp increase for each 
successive period or the connection shall be terminated . (See 2-1.3.2) 


FRS372 Consumers using Extended Format connections shall see the Timestamp increase for 
each successive period. If the consumer receives a packet with an out-of-sequence Timestamp, 
it shall drop the packet unless the Consumer Fault Counter has reached the Max Fault Number; 
in which case the connection shall be terminated. (See 2-2.6.3.1) 


Messaging with production repeated offers the additional advantage of using the most current 
data. 
Lost, Corrupted and Delayed Message Transmission 


Due to external disturbances it may be possible for the message to be corrupted as it is 
transmitted from the producer to the consumer, as shown in Figure 2-1.27. 


FRS835 If a corrupted message is detected at the standard layer, it shall be discarded and not 
presented to the application. 
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This will result in an expiration of the consumer activity monitor or the data age will exceed the 
network time expectation and the consumer terminates the connection (See 2-1.3.2) and goes to 
the defined safety state. 


FRS86 If the transmitted CRC-Sx and data are checked and any found to be in error or the data 
cross-check is found to be in error, the consumer shall either drop the packet (Extended Format 
AND Consumer_Fault_Count less than Max_Fault_Number), or terminate the connection and 
go to the defined safety state (Base format or Extended Format AND Consumer_Fault_Count 
greater or equal to Max_Fault_Number). (See 2-1.3.2) 


Figure 2-1.27 Sequence Diagram of a Corrupted Producer To Consumer Message 


Producer Consumer 


Safely Message (Data, Mode, Ping, Timestamp 


=1, CRC-Sx) 


Consumer Activity 
Monitor 
Network Time 
Expectation 


EPI 


Ss 
ately Message (Data, Mode, Ping, Timestamp = 2 


CRC-Sx) {Ignore 
Message 
= 
& 
Safer 
ly Message (Data, Mode, Ping, Timestamp = 3, CRC-Sx) c 
, [Ignore 
Message 


Due to external disturbances it may be possible for the message to be lost as it is transmitted 
from the producer to the consumer, as shown in Figure 2-1.28. This will result in an expiration 
of the consumer activity monitor or the data age will exceed the network time expectation and 
the consumer terminates the connection (See 2-1.3.2) and goes to the defined safety state. 
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Figure 2-1.28 Sequence Diagram of a Lost Producer to Consumer Message 


Producer F Consumer 


Salety Msg (Data, Mode, Ping, Timestamp =1, CRC-Sx) 


Monitor 


Consumer Activity 
Network Time 
Expectation 


EPI 


Safety Message (Data, Mode, Ping, Timestamp =2, CRC-Sx) 


Ignore 
Message 


EPI 


V2. Safely Message (Data, Mode, Ping, Timestamp =3, CRC-Sx) 


| ___.f Ignore 
Message 


Messages may be delayed in transmission. FRS87 If a message is delayed such that it is 
received 


1. beyond the consumer activity monitor (link-triggered application) or 
2. the data age exceeds the network time expectation, 


then all further messages are ignored, and the connection shall be terminated. 


In both cases the consumer terminates the connection (See 2-1.3.2) and goes to the defined 
safety state. This behavior is shown in Figure 2-1.29. 
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Figure 2-1.29 Sequence Diagram of a Delayed Message 


Producer Consumer 


Monitor 


Network Time 
Expectation 


Consumer 


Ignore 
Message 


Safely Message (Data, Mode, Ping, Timestamp =2, CRC-Sx) 


Ignore 
Message ) 


Safety Message (Data, Mode, Ping, Timestamp =3, CRC-Sx) 


Ignore 
Message 


2-1.8.3.3 Lost, Corrupted or Delayed Message Transmission with Production Repeated 


Due to external disturbances it may be possible for the message to be corrupted as it is 
transmitted from the producer to the consumer, as shown in Figure 2-1.30. In order to increase 
the availability of the overall system, production may be repeated. 
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Figure 2-1.30 Sequence Diagram of a Corrupted Producer to Consumer Message With Production 
Repeated 


Producer Consumer Safety App. 
Safety Message (Mode, Pj 
Ping, Data, Data _Time_Stamp =1, CRC-Sx) ni 
| Message 
Used by 
Safety Message (Mode 
le, Ping, Data, Data, Ti P : _ 
1. i. 1_Time_Stamp =: e 
P =2, CRC-Sx) i 
Safety Message (Mode, Ping, Data, D: 
|. b lata_Time_Stamp =3, CRC-Sx) ik Valid . 
ink Vali 
Safety Me ae 
lessage (Mode it a se 
le, Ping, Data, Data_Time_Stamp =4, CRC-Sx) ne 
., Message 
Used by 
Safety Message (Mode, Ping, Data, Data Time. Stamp =5, CRC. S) i —_ 
\_Time_Stamp =5, CRC-Sy 
Safety Message (Mod. : 
1@ (Mode, Ping, D; 2 
ng, Data, Oata_Time_Stamp =6, cRe-sxy 5 
: 5 
= Y Safety Me 
ly Message (Mode, Pi ; 
; » Ping, Data, Data Time 3 
& »_Stamp =7, CRO-Sx) is oa 
__ Message 
Used by 


Consumer 


If there are errors that are detected in the standard layers, the messages can be discarded, as 
long as a valid and expected message is received within the consumer activity monitor and the 
age of the data does not exceed the network time expectation. 


FRS88 Valid repeated messages shall be overwritten. The most recent valid message is used 
by the application. 


Due to external disturbances, it may be possible for a series of messages to be delayed resulting 
in a lost connection. This sequence is shown in Figure 2-1.31. If no valid messages are 
received before the consumer periodic timer expires, the connection will be terminated (See 2- 
1.3.2). 
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Figure 2-1.31 Sequence Diagram of a Connection Terminated Due to Delays 
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Terminate 
connection 
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A valid link message that fails a Safety CRC check will cause the consumer to conclude the 
underlying link is untrustworthy and, depending on the format used and/or number of 
occurrences, could cause the connection to be terminated (See 2-1.3.2). This sequence is 
shown in Figure 2-1.32. 


Figure 2-1.32 Sequence Diagram of a Failure of Safety CRC Check 
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2-1.8.3.4 Single-Cast Ping 
In order to maintain consistent delay timing between producers and consumers a ping request 
and response message transaction sequence is used. The producer is fully described in section 
2-2.4 and the consumer is fully described in section 2-2.6. This sequence of messages for a 
single-cast ping is shown in Figure 2-1.33. 
Figure 2-1.33 Sequence Diagram of a Single-Cast Ping - Normal Response 
Producer Consumer 
Safe 
inecuest lig safely Message (Data, Mode, Ping=3, Timestamp =1, CRC-Sx) —Ping 
panes Response 
_ Node 1 
co 
a a g=3con Set cROY 
ae 
= 
Ping 
Success, 
New Ping 
Request a ine 
_ Node 2 
_o 
= 
Ee 
= 
mh eee 
FRS89 At each single-cast producer ping interval, the ping count shall be incremented in the 
next available safety message header. 
FRS90 The single-cast producer ping interval shall be a multiple of the EPI; ping requests shall 
be made at rates based on the Ping _Interval_EPI_Mulitplier 
When a single-cast consumer sees a change in the ping count the consumer generates a time 
coordination message. 
The time coordination message (See 2-1.8.3.1) must be received by the producer within a 
prescribed time frame (see FRS229). If the time coordination message is not received within 
that time frame the connection is terminated. (See section 2-1.3.2) 
2-1.8.3.5 Multi-Cast Ping on DeviceNet Safety 


In order to maintain consistent delay timing between producers and consumers a ping request 
and response message transaction sequence is used. 


FRS92 For DeviceNet Multi-cast connections, a separate message shall be used to 
communicate time correction information form the produce to each multi-cast consumer. 
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The producer is fully described in section 2-2.4 and the consumer is fully described in sec 
2-2.6. This sequence of messages for multi-cast ping is shown in Figure 2-1.34. For clarity the 
time correction message is shown on a separate diagram. 


Figure 2-1.34 Sequence Diagram of a Successful Multi-Cast Ping, DeviceNet 
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During each multi-cast producer ping interval, a ping request will be sent from the multi-cast 
producers to multi-cast consumers requesting a response. 


FRS94 All multi-cast consumers shall respond to a change in the ping request value, consumers 
other than consumer | shall wait Consumer_Number -1 times the EPI to reply. 
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All of the multi-cast consumers must respond within the ping interval of the request or the next 
one. 


FRS95 Time correction messages shall be sent to the multi-cast consumers at a rate to ensure 
that each consumer gets a time correction message within a single producer ping interval 


2-1.8.3.6 Multi-Cast Ping On Non - DeviceNet Networks 


In order to maintain delay timing between multi-cast producers and its consumers, a ping 
request and response is used. 


FRS96 For Non-DeviceNet networks the time correction message shall be concatenated with 
the safety data message and sent as a single message. 


The producer is fully described in section 2-2.4 and the consumer is fully described in section 
2-2.6. This sequence of messages for multi-cast ping is shown in Figure 2-1.35. 


Figure 2-1.35 Sequence Diagram of a Successful Multi-Cast Ping, Non-DeviceNet 
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During each producer ping interval, a ping request is sent from the multi-cast producers to 
multi-cast consumers requesting a response. 
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2-1.8.3.7 


Multi-Cast Ping — Retry with Success 


This sequence of messages for a multi-cast ping with retries is shown in Figure 2-1.36. The 
time correction connection is not shown for clarity. 


Figure 2-1.36 Sequence Diagram of a Multi-Cast Ping Retry 
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2-1.8.3.8 


FRS98 If a multi-cast time coordination message is lost or delayed past the 
(Timeout_Multiplier.PI +2) ping intervals, an error shall be generated and the connection 
closed . 


Multi-Cast Ping — Retry with Timeout 


This sequence of messages for a multi-cast ping with retries and timeout is shown in Figure 2- 
1.37. The time correction connection is not shown for clarity. 
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Figure 2-1.37 Sequence Diagram of a Multi-Cast Ping Timeout 
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Tf the ping response continues to be delayed, the producer will indicate a fault in the producer 
status for the specific consumer and the consumer will go to the defined safety state. If the 
ping was delayed due to a fault in the consumer, the consumer will have already gone to a safe 


state. 


2-1.9 Safety Configuration 


This section gives an overview of the configuration procedure and data. Complete details of the 
safety configuration process are given in Chapter 7 of this volume. 


There are three methods identified for configuring safety devices: 
Configuration as part of the forward open 2-1.9.1.2 
Configuration by separate transfer from an originator 2-1.9.1.2 
Configuration from a workstation 2-1.9.1.1 


The relation ship of these configuration processes is shown in Figure 2-1.38 
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2-1.9.1 


2-1.9.1.1 


2-1.9.1.2 


2-1.9.1.3 


Figure 2-1.38 Methods of Configuring Devices 


2 
Safety Configuration Data 


Safety devices will require configuration data be stored and maintained for both the device 
configuration and the connection configuration. 


FRS100 It shall be permissible to combine the device and the connection configuration. 


The overall safety configuration is specific to the network and application being used and may 
require more data (i.e. configuration by an application configuration tool and a network 
configuration tool). The connection configuration information is defined in Chapter 6. 


Configuration from Workstation 


The process for configuration of a safety device from a workstation is fully described in the 
Chapter 7. When either an originating device or a target device is configured from a 
workstation, the modes of the devices and the process of configuring a device shall be managed 
such that the device will meet the desired SIL level requirements upon the completion of the 
configuration process. 


Configuration as Part of Connection Establishment 
The overview of the operations required to initially configure device connections is described 
in this section. A complete definition of connection establishment is found in Section 2-3. 
Types of safety opens 
There are two types of safety opens defined, Type 1 SafetyOpen and Type 2 SafetyOpen. 
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2-1.9.1.3.1 


2-1.9.1.3.2 


A Type | SafetyOpen has all of the data necessary for the configuration of a safety device. A 
Type 2 SafetyOpen does not contain all of the data necessary for the configuration of a safety 
device. Type 2 SafetyOpens may perform a SCID check to ensure that the originator and target 
are in agreement on the configuration data of the target depending on the value of the SCID 
(refer to FRS163). If a Type 2 SafetyOpen is used with the option to not perform the SCID 
check, instructions shall be placed in the user manual for the user to check that configurations 
used are as expected. (refer to FRS103) 


A Type | SafetyOpen shall not be limited to EDS configurations. Any settable attribute data, 
regardless of the attribute’s relation to safety, may be included within a Type 1 SafetyOpen. 


Configuration Using a Type 1 SafetyOpen 


At the time a connection is established, the originator sends a forward open with a safety 
network segment on EtherNet/IP and SERCOS III or SafetyOpen on DeviceNet that contains 
the originator UNID, the target UNID, the Safety Configuration Identifier (the configuration 
data is omitted for Type 2 SafetyOpens). The target device verifies the target UNID matches 
it’s UNID and verifies ownership, validity of data and Safety Configuration Identifier match 
prior to applying the configuration data. 


FRS104 Once the producer has correctly verified a successful response to a forward open 
message, the producer shall start producing safety data at the periodic rate but with the run/idle 
bit set to idle (single-cast) or the Consumer_Active_Idle set to Idle (multi-cast). 


The producer shall send a ping request on the first message. 


FRS106 The producer shall maintain the run/idle or Consumer_Active_Idle bit idle until the 
initial Time Coordination sequence is successfully completed. 


FRS107 The consumer shall remain in a safety state until the initial ping sequence is 
successfully completed. 


The consumer will know the sequence is successful when the there are no faults indicated and 
the Run_Idle bit or Consumer_Active_Idle bit are set to the run state. A detailed explanation of 
these interactions is contained in Section 2-6, Safety Connection Establishment. 


Configuration Using a Type 2 SafetyOpen 


FRS 108 If a device either responds to a Type 2 SafetyOpen with a SCID mis-match or requests 
a download because it is being replaced, the following sequence shall be followed. 


e The originator sends a Type 2 SafetyOpen to the target device 

The target responds with a mode state error 

The originator calls the Safety Application to perform a download 

The Safety Application performs and verifies the download. 

The download may be a series of commands to the device or 

The download may be a Type | SafetyOpen. 

The originator repeats the Type 2 SafetyOpen to establish the connection verify the 
configuration. 


cooceee 
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2-1.9.2 Safety Network Configuration Tool 

The safety network configuration tool (SNCT) shall support the functionality outlined in this 
section. 

2-1.9.3 Safety Configuration Data CRC (SCCRC) 

The SCCRC is defined in Section 2-3.1.1. 


2-1.9.4 Safety Configuration Identifier (SCID) 


All safety configurations shall be accompanied by a Safety Configuration Identifier to identify 
the configuration. The format and contents of the Safety Configuration Identifier is defined in 
Section 2-3.1.1 


FRS111 The SNCT which generates a safety device configuration shall generate a unique 
Safety Configuration Identifier . 


SRS47 The SCID shall change when a device’s configuration data changes. 


2-1.9.5 Device Replacement 


FRS112 The user safety manual shall contain instructions instructing the user “The 
replacement of safety devices requires that the replacement device be configured properly and 
operation of the replacement device shall be user verified. 


2-1.9.5.1 Devices Configured from SafetyOpen/Forward Open 


If a device configured via a safety open is replaced, the originator will attempt to re-establish 
the connections and configure the new device. The actions necessary for these operations are 
detailed in section 2-3. 


When the safety open is received by the new device, the Safety Configuration Identifier will 
not match the Safety Configuration Identifier contained in the SafetyOpen. Once the 
SafetyOpen TUNID is validated as correct and the safety data in the SafetyOpen is validated 
than the configuration is applied by the device. 


2-1.10 Diagnostics for Communication Errors 


Safety Devices on CIP Networks should support any diagnostic features specified in the CIP 
Common Specification (Volume 1), and the appropriate network specific specification, either 
the DeviceNet Specification (Volume 3) or the EtherNet/IP Specification (Volume 2). 
Communication error diagnostics for Safety Devices on SERCOS III networks is outside the 
scope of this specification. 


2-1.10.1 Rules for Device Configurations 


FRS116 The following Rules shall apply to device configuration: 
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2-1.10.2 


2-1.11 


2-1.11.1 


2-1.11.2 


2-1.11.3 


2-1.11.4 


e Devices being configured shall not have any active safety connections and shall not be in 
the executing mode. 

¢ Once configuration of a device starts, the device shall remain in the non-operational mode 
until the configuration process is successfully completed. This mode shall be maintained 
through power cycles. 

e Ifa device is in an operational mode (e.g.. has active connection or is in executing mode), it 
shall reject any configuration messages. 


Connection Restart 


A restart may be needed if a connection is terminated for a safety event or terminated from the 
application. It may also be desirable to restart a single connection rather than the entire 
connection set for a device. The restart sequence is the same message sequence from the 
originator to the target as defined in Section 2-3. Due to the nature of some of the errors, it 
may require a power cycle or module replacement before the error is cleared. 

Safety Device Requirements (Device Behavior) 

The safety device requirements define the behavior that all devices need to implement shall 
support proper operation of the safety protocol. 


Safety Input Requirements 


FRS117 If a safety state exists for the safety-input device, the device shall transmit safety data 
and the Run_Idle bit shall be set to the idle state upon detection of a fault by the input circuit 
diagnostics. 


FRS118 Changes in the state of the physical process inputs of a safety device shall be 
transmitted at the next available periodic update time. 

Output Requirements 

All safety outputs will go to a safety (off) state on detection of a failure. 

Safety output devices may provide the output point status. If output status is needed it should 
be sent via a single-cast or multi-cast input safety connection. 

Safety Device Communications Failure 

FRS120 A failure in a background communications diagnostic shall cause all 
producer/consumer safety connections for that device to be terminated. (See 2-1.3.2) 
Safety Device Major Faults 


FRS121 If there is a major fault in a safety device that causes the device to go into a safety 
state, the device shall be reset or restarted. 


FRS122 In order to clear a major fault in a system the device shall execute and pass all internal 
self-tests prior to accepting or initiating any safety connections. 
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2-1.11.5 


2-1.11.6 


2-2 


2-2.1 


Safety-Related Program Detected Safety Event 


It is expected that if a safety-related program detects a safety event, the safety-related program 
will take a safety action, applying required safety data to the outputs. 


Safety Device Loss of Power 


A loss of device power in a safety device will cause the producer/consumer safety connections 
for that device to terminate. The powering up device will then follow standard safety start up 
procedures to rejoin the system. 


Safety Protocol 


The safety layer is a layer of service residing between the standard CIP transport layer and the 
safety application layer as shown in Figure 2-1.2. This safety layer need not be directly 
addressable in the CIP framework; rather it is a behavior associated with a connection between 
applications exchanging data in a SIL 3 application. This behavior is implemented, in some 
products, as the Safety Validator object as described in section 2-2.2. 


Note: There may be multiple methods of accomplishing this desired behavior. The objects in 
this chapter are to be considered a reference model. Individual products and applications may 
choose to implement this behavior, as they deem necessary. However, this behavior needs to 
be expressed here to form a basis for product development. 


High Level View of a Safety Device 


Figure 2-2.1 shows a reference model of a safety device containing one or more safety 
application objects. Each safety application objects functions with a pair of Safety Validator 
objects to exchange SIL 3 data between the CIP transport layer and the safety I/O electronic 
circuitry. These electronics are designed to provide a level of error detection and fault isolation 
suitable for SIL 3 applications. Each of the two Safety Validator objects is associated with a 
network connection on networks such as DeviceNet or Ethernet/IP. This model assumes a 
1002 Safety Topology in which two independent CPUs participate in the safety protocol. 
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2-2.2 


2-2.3 


executed on 


Figure 2-2.1 Safety Device Reference Model Entity Relation Diagram 
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Safety Validator Object 


The Chapter 5-5 of this volume defines a Safety Validator object from which both the 
Safety ValidatorServer and Safety ValidatorClient functions are implemented. 


The next section describes the general principles and common attributes of these two safety 
layer functions. 


Relationship between Safety ValidatorServer and Safety ValidatorClient 


Figure 2-2.2 shows a high level view of two devices interchanging data via a 

Safety ValidatorClient and a Safety ValidatorServer. A safety producing application uses a 
Safety ValidatorClient to send safety data to a safety consuming application that uses a 
Safety ValidatorServer. 


Note that only one of the redundant paths interfaces to the CIP transport layer. The A+B 
(actual and complement) data is encapsulated in a single transport frame and only one 
processor is involved in the reception and transmission of the data frames 
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2-2.4 


2-2.4.1 


Figure 2-2.2 Two Devices Interchanging Data via a SafetyValidatorClient and a 
SafetyValidatorServer 
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Extended Format Time Stamp Rollover Handling 


The Extended format requires coordinated synchronization between producers and consumers 
on connection establishment along with maintenance operations to detect and handle Time 
Stamp rollover events. The following sections graphically show these operations for each 
unique case. The example code shows these operations in their proper place in the code as 
well. 


Single-Cast, Originator Consumer, Target Producer 


When single-cast connections are originated by the consumer (i.e. single cast inputs), the 
originator has to provide initialization values in the SafetyOpen. The target uses these values 
to initialize production parameters. 


FRS376 The rollover count used in the Extended Format Single-Cast CRC shall be zero until 
the initial Time Coordination exchange has been completed. 


The complete process is shown below in Figure 2-2.3 
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Figure 2-2.3 Single-Cast, Originating Consumer Target Producer 
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ENDIF 


IF (Run_Idie == Idle) AND (Init Complete Out —— 0) AND’ 1 RC_Used_In_CRC =TS_Rollover_Count 
Data Time. Stamo==0) | Last Time Stamp. For Rollover =Data. Time Stamp 


Last_Time Stamp For_Rollove) 
THEN { TS_Roliover Count =TS_Rollover_ Count +1} 
ENDIF 
RC_Used_In_CRC=TS_Rollover_Count 
Last_Time_Stamp_For Rollover =Data_Time_Stamp 


} 
ENDIF 


The time between the generation of the Safety Open and the Consumers processing of the first packet 
produced after the producers reception of the Time_Coordination message must be < 8.3 seconds. 


2-2.4.2 Single-Cast, Originator Producer, Target Consumer 


FRS379 When Extended Format single-cast connections are originated by the producer (i.e. 
outputs), the target consumer shall provide initialization values in the SafetyOpen Response. 


The originator producer uses these values to initialize production parameters. 


The complete process is shown below in Figure 2-2.4. 
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Figure 2-2.4 - Single-Cast, Originator Producer, Target Consumer 
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os 


THEN {TS Rolover Gount=TS Follow Count + | erator: (Dota Tine Stema.CRC sea | |THENERO Ueee Ir CRC Oro00 
ENDIF al be IMRLCRC Seed | | ELSE {IF unsgnedData Time Stamp<Last Time Stamp For Rolove) 
RC Used In CRC=TS Rolover Count Data Time Stamp / f THEN TS Rollover Count=TS Robover Count + 3 

Last Tine Slanp For Rolover= Data Tine Stamp i a! ENOIF 


H H FC Used In CRC=15 Rollover Count 
H H Last Time Stamp For Rolave' = Data Time Stamp 


a 
ENDIF 


The time between the generation of the Safety Open Response and the Consumers processing of the first packet 
produced after the producers reception of the Time_Coordination message must be <8.3 seconds. 


2-2.4.3 Multi-cast, Originator Consumer, Target Producer 


FRS377 When Extended Format multi-cast connections are originated by the consumer (i.e. 
multi-cast inputs); the target producer shall provide initialization values in the SafetyOpen 
Response. 


The target consumer uses these values to initialize production parameters. The values the 
target producer sends in the SafetyOpen Response differs depending on whether this is the 1“ 


consumer to request a connection or not. 


FRS378 The active seeding of the CRC with the rollover count in Extended Format Multi-cast 
messages shall begin immediately on first production. 


The complete process is shown below in Figure 2-2.5 
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Figure 2-2.5 - Multi-Cast, Originator Consumer, Target Producer 


Multi-Cast 
Originator Consumer — Target Producer 


Consumer Producer 


IF 1 Consumer 

Originator Target THEN { Initial TS = Producer Clk Count 

Initial Rollover Value = Producer Clk Count 

H Safety Open: () Hl + Initial RC_Offset 

\ Y Initial_RC_Offset = Initial RC_Offset+ 1 
Last_Time Stamp For Rollover = Initial TS 
TS_Rollover_Count = Initial Rollover Value} 

ELSE { Initial TS = Last Time Stamp For Rollover 
Initial Rollover Value = TS_Rollover_Count} 

ENDIF 


Safety Open Response: (Initial TS, Initial_Rol| 


ies cea if 


TS Rollover Count = initial Rollover Value 


IF unsigned(Data Time Stamp<Last Time Stamp For Rollover) 
THEN{ TS Rollover Count=TS. Rollover Count + 1} 

ENDIF 

RC_Used In CRC=TS Rollover Count 
Last_Time_Stamp For Rollover =Data_Time_Stamp 


i TS = Producer Clk_Count 
Must be <8.3. ' 


Production(Data_Time Stamp, RC_Used 


IF unsigned(Data_Time Stamp 
<Last_Time_Stamp For Rollover) 

THEN{TS Rollover Count=TS Rollover Count + 7} 

ENDIF 

RC_Used In CRC=TS Rollover_Coun 

Last_Time_Stamp_For Rollover =Data_Time_Stamp 


The time between the generation of the Safety Open Response and the Consumers processing of the first 
packet must be < 8.3 seconds. 


2-2.5 Safety ValidatorClient Function definition 


The Safety ValidatorClient is the embodiment of the safety layer that augments a standard CIP 
connection to transmit SIL 3 data. It coordinates the production of application data with a peer 
instance of the Safety ValidatorClient. 


2-2.5.1 Safety Production 


This section describes the production of data and the interfaces between the application, the 
Safety ValidatorClient and the underlying link layer. Note that the focus is on the 

Safety ValidatorClient run-time behavior and its interfaces. The application itself must be of 
high integrity and this can be accomplished in many ways and is ultimately a vendor design 
decision; however later in this document, a reference model is presented of an architecture has 
been qualified for SIL 3 requirements in specific instances. This reference model is for 
informative purposes only. 


FRS123 Safety_Data_Out is produced at a periodic rate, referred to as the Expected Packet 
Interval (EPI). The SafetyValidatorClient shall sample, capture, and time stamp the data to be 
sent every EPI time period. 
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Figure 2-2.6 Safety Production Data Flow 
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2-2.5.1.1 Producing Application Interface 


FRS124 The producing application provides Safety_Data_Out to the Safety ValidatorClient. 
The Safety ValidatorClient shall build the Mode_Byte, Actual_Data, and Complement_Data, 
and Time stamp section. (see section 2-1.7.1 for formats) 


FRS125 The Safety ValidatorClient shall provide safety connection status back to the producing 
application for each consumer. 


2-2.5.1.1.1 | Safety Data Production Logic 


This section describes the logic that shall be followed by all safety data producers. The actual 
implementation of the logic may vary, but equivalent results shall be obtained. 

The logic in this document assumes an asynchronous producing application that makes the 
safety data available to the Safety ValidatorClient. 


Definitions for the variables used in the safety data production logic can be found in section 2- 
45. 


2-2.5.1.1.1.1 Example Safety Data Production Cold Start Logic 


The production logic to initiate a cold start of a connection is: 


CLL 

// Cold start after connection establishment processing 
TUM 

// This Logic should be executed at the transition of the 

// producing connection from closed to open. 

// For Single-Cast connections this logic may 

// be performed any time the connection is Opened or Re-Opened. 
THUMM 
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Ping_Interval_EPI_Count = 0, 
RR_Con_Num_Index_Pntr = Max_Consumer_Number, 


// Initialize the ping count in the safety message to 0 
Mode_Byte.Ping_Count = 0, 


// Time_Drift_Per_Ping_Interval, the minimum value is 1 
Time_Drift_Per_Ping_Interval = 
Roundup(EPI * Ping_Interval_EPI_Multiplier / 320000), 


FOR (Consumer_Num = 1 to Max_Consumer_Number), 

{ 
// Producer Dynamic Variables 
Consumer_Active_Idle[Consumer_Num-1] = Idle, 
S_Connection_Fault{Consumer_Num-1] = OK, 
Producer_Reved_Time_Value[Consumer_Num-1] = 0x0000, 
Consumer_Time_Correction_Value[Consumer_Num-1] = 0x0000, 
Ping_Int_Since_Last_Time_Coord_Msg_Count[Consumer_Num-1] = 0x0000, 
Consumer_Time_Value[Consumer_Num-1] = 0x0000, 
Producer_Fault_Counter[Consumer_Num-1] = 0, //For ExtendedFormat only 


// Producer Derived Variables 


// Time_Drift_Constant, the minimum value is 1. (Time_Drift_Constant is not 
// saved but is used in the calculation of the 
// Connection_Correction_Constant below.) 
Time_Drift_Constant = 
Roundup((Timeout_Multiplier.PI [Consumer_Num-1] +1) * EPI * 
Ping_Interval_EPI_Multiplier / 320000), 


// Connection_Correction_Constant 
Connection_Correction_Constant[Consumer_Num-1] = 
Time_Drift_Constant + | - Time_Coord_Msg_Min_Multiplier [Consumer_Num-1], 


// Time_Coord_Response_EPI_Limit 

Time_Coord_Response_EPI_Limit[Consumer_Num-1] = Roundup((5000000 + 
(Time_Coord_Msg_Min_Multiplier[Consumer_Num-1]*128) + 
(EPI * (Consumer_Num — 1))) / EPI), 


// Time_Coord_Response_EPI_Limit has a maximum value of 1000 
IF (Time_Coord_Response_EPI_Limit[{Consumer_Num-1] > 1000), 
THEN 

{ 


} 
ENDIF 


Time_Coord_Response_EPI_Limit[Consumer_Num-1] = 1000, 


} 
ENDFOR 
IF (ExtendedFormat), 
THEN 
{ 
RC_Used_in_CRC = 0x0000 
IF (Multi-Cast), 
THEN 
{ 
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// The rollover value is initialized to the local Time Stamp clock value plus an offset 
// This is considered as a random number for this purpose 
Initial_TS for SafetyOpenResponse = Producer_Clk_Count 
Initial_Rollover_Value for SafetyOpenResponse = 

Producer_Clk_Count + Initial_RC_Offset 
Last_Time_Stamp_For_Rollover = Initial_TS 
TS_Rollover_Count = Initial_Rollover_Value 


ENDIF 
IF (Single-Cast AND Originator), 
THEN 


Last_Time_Stamp_For_Rollover = Initial_TS from SafetyOpenResponse 
TS_Rollover_Count = Initial_Rollover_Value from SafetyOpenResponse 


ENDIF 
IF (Single-Cast AND Target), 
THEN 


Last_Time_Stamp_For_Rollover = Initial_TS from SafetyOpen 
TS_Rollover_Count = Initial_Rollover_Value from SafetyOpen 


ENDIF 


} 
ENDIF 


TUM 
// end, Cold start after connection establishment processing 
TE 


2-2.5.1.1.1.2 Example Safety Data Production Multi-Cast Consumer re-start Logic 


The logic allows individual multi-cast consumers to be stopped and restarted while the multi- 
cast production continues to other consumers. 


This section defines the logic needed to restart an individual consumer, but it does not represent 
an efficient implementation of how to detect that the individual connections has been restarted. 


TUM 
// Re-initialization of Multi-Cast prodution to individual consumers 
TUM 
// This Logic should be executed after a multicast consumer performs 
// a successful open to a multi-cast producer while the production 
// is in process to re-initialize production to that consumer number 
TUM 
FOR (Consumer_Num = | to Max_Consumer_Number), 
{ 
IF (Consumer_Open(Consumer_Num-1)transitions from Closed to Open) 
THEN 
{ 
// Producer Dynamic Variables 
Consumer_Active_Idle[Consumer_Num-1] = Idle, 
S_Connection_Fault{Consumer_Num-1] = OK, 
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Producer_Reved_Time_Value[Consumer_Num-1] = 0x0000, 
Consumer_Time_Correction_Value[Consumer_Num-1] = 0x0000, 
Ping_Int_Since_Last_Time_Coord_Msg_Count[Consumer_Num-1 ] = 0x0000, 
Producer_Fault_Counter[Consumer_Num-1] = 0, //For ExtendedFormat only 


// Producer Derived Variables 
// Time_Drift_Constant, the minimum value is 1 
//(Time_Drift_Constant is not 
// saved but is used in the calculation of the 
// Connection_Correction_Constant below.) 
Time_Drift_Constant = 
Roundup((Timeout_Multiplier.PI [Consumer_Num-1] +1) * EPI * 
Ping_Interval_EPI_Multiplier / 320000), 
// Connection_Correction_Constant 
Connection_Correction_Constant[Consumer_Num-1] = 
Time_Drift_Constant + 1 - Time_Coord_Msg_Min_Multiplier [Consumer_Num-1], 
// Time_Coord_Response_EPI_Limit 
Time_Coord_Response_EPI_Limit{Consumer_Num-1] = Roundup((5000000 + 
(Time_Coord_Msg_Min_Multiplier[Consumer_Num-1]*128) + 
(EPI * (Consumer_Num — 1))) / EPID, 


// Time_Coord_Response_EPI_Limit has a maximum value of 1000 
IF (Time_Coord_Response_EPI_Limit[Consumer_Num-1] > 1000), 


THEN 
{ 
Time_Coord_Response_EPI_Limit{Consumer_Num-1] = 1000, 
} 
ENDIF 
) 
ENDIF 
} 
ENDFOR 
IF (ExtendedFormat), 
THEN 
{ 


Initial_TS for SafetyOpenResponse = Last_Time_Stamp_For_Rollover 
Initial_Rollover_Value for SafetyOpenResponse = TS_Rollover_Count 


} 
ENDIF 


2-2.5.1.1.1.3 Example Combined Data Production 


The following is the common required logic of the Safety ValidatorClient for all (see section 2- 
1.6) of safety connections. 


TUM 

// start of EPI Safety Data production processing 
TU 

// This logic assumes that the application has passed the Safety 
// Data and Application_Run_Idle to the Safety Validator. 

HW 

TMU 
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// Capture the time to be used for the time stamp 
Producer_Safe_Data_TS = Producer_Clk_Count, 


// Check if it is time to increment the Ping Count 
Ping_Interval_EPI_Count = Ping_Interval_EPI_Count + 1, 


IF (Ping_Interval_EPI_Count >= Ping_Interval_EPI_Multiplier), 
THEN 
{ 
Increment Mode_Byte.Ping_Count, 
Ping_Interval_EPI_Count = 0, 
} 
ENDIF 


// Set the remainder of the Mode_Byte bits 
Mode_Byte.Run_Idle = Application_Run_Idle, 
Mode_Byte.TBD_Bit =0, 
Mode_Byte.TBD_2_Bit =0, 


// Execute the safety producer, connection type specific functions 
IF (Connection_Type == multi-cast), 

THEN 

{ 


multi_cast_producer_function(), 


single_cast_producer_function(), 


} 
ENDIF 


// set Mode_Byte redundant bits (2:4) to the correct values 

Mode_Byte = (Mode_Byte AND 0xe3)OR((Mode_Byte>>3) AND Oxlc XOR 0x14), 
Calculate CRC(s) based on the format used 

Trigger the sending of the Data Message, 


// Tf on DeviceNet and Multi-cast, send the Time Correction 

// Message if it is time. 

IF ((Connetion_Type == DeviceNet) AND 
(Send_Time_Correction_Message == 1)), 

THEN 

{ 
Trigger the sending of the Time Correction Message, 
Send_Time_Correction_Message = 0, 

} 

ENDIF 

TUM 

// end of safety data production processing 

TUM 


TLL 
// Start of single-cast production function 
TMM 
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single_cast_producer_function() 

// Check if a Time Coordination message has been received in 

// the allotted time. 

IF (Ping_Interval_EPI_Count == 8), 

THEN 

{ 
Increment Ping_Int_Since_Last_Time_Coord_Msg_Count[0], 
IF (Ping_Int_Since_Last_Time_Coord_Msg_Count[0] 
>= (Timeout_Multiplier.PI [0] + 2)), 

THEN 

{ 


} 
ENDIF 


S_Connection_Fault[0]=Faulted, 


} 
ENDIF 


//Hold Data_Time_Stamp = 0 until time coordination msg received 
IF(Consumer_Active_Idle[0] == Idle), 
THEN 
{ 
Mode_Byte.Run_Idle = Idle, 
Time_Stamp_Section.Data_Time_Stamp = 0x0000, 
IF (ExtendedFormat), 
THEN 
{ 
// Set seed value to 0 for time stamp equal to 0 
RC_Used_in_CRC = 0x0000 
} 
ENDIF 


ELSE 


Time_Stamp_Section.Data_Time_Stamp = Producer_Safe_Data_TS + 
Consumer_Time_Correction_Value[0], 
IF (ExtendedFormat), 
THEN 
{ 
// check for rollover 
IF (unsigned compare(Time_Stamp_Section.Data_Time_Stamp < 
Last_Time_Stamp_For_Rollover)) 
THEN 
{ 


} 

ENDIF 

// set the seed value 

RC_Used_in_CRC = TS_Rollover_Count 

// save the time stamp 

Last_Time_Stamp_For_Rollover = Time_Stamp_Section.Data_Time_Stamp 


TS_Rollover_Count = TS_Rollover_Count + 1 


} 
ENDIF 


} 
ENDIF 


END single_cast_ producer_function() 
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TUM 
// end of single-cast processing 
THU 


TUM 

// Start of multi-cast production function 
CLL 
multi_cast_producer_function() 

// Check if its time to start sending Time Correction messages 

/ Time Correction messages are sent starting at the 8" EPI production 
// within the Ping interval 

IF (Ping_Interval_EPI_Count == 8), 

THEN 

{ 


} 
ENDIF 


RR_Con_Num_Index_Pntr = 0, 


// Check if a Time Coordination message has been received in 

// the allotted time. 

IF (RR_Con_Num_Index_Pntr < Max_Consumer_Number), 

THEN 

{ 
Increment Ping_Int_Since_Last_Time_Coord_Msg_Count{[RR_Con_Num_Index_Pntr], 
IF (Ping_Int_Since_Last_Time_Coord_Msg_Count[RR_Con_Num_Index_Pntr] 
>= (Timeout_Multiplier.PI [RR_Con_Num_Index_Pntr] + 2)), 


THEN 
{ 
Set S_Connection_Fault{RR_Con_Num_Index_Pntr]=Faulted, 
} 
ENDIF 
ENDIF 


// Check if its time to send an active non-errored Time Correction 
// message 
IF ((RR_Con_Num_Index_Pntr < Max_Consumer_Number) AND 
(Consumer_Active_Idle[RR_Con_Num_Index_Pntr] == Active)), AND 
(Consumer_Open[RR_Con_Num_Index_Pntr] == Open) AND 
(S_Connection_Fault{RR_Con_Num_Index_Pntr] == OK) 
THEN 
{ 
Send_Time_Correction_Message = 1, 
Mcast_Byte.Consumer_# = RR_Con_Num_Index_Pntr + 1, 
Mcast_Byte.Multi_Cast_Active_Idle = 
Consumer_Active_Idle[RR_Con_Num_Index_Pntr], 
Time_Correction_Section.Time_Correction_Value = 
Consumer_Time_Correction_Value[RR_Con_Num_Index_Pntr], 
Set Mcast_Byte.Parity_Even to the correct value, 
MCast_Byte_2 = ((MCast_Byte XOR OxFF) AND 0x55) OR 
(MCast_Byte AND 0xAA) 
Calculate CRC of time correction message, 


ELSE 
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/Noad null TIME_CORRECTION Section, 
Mcast_Byte.Consumer_# = 0, 
Mcast_Byte.Multi_Cast_Active_Idle = Idle, 
Time_Correction_Section.Time_Correction_Value = 0, 
Set Mcast_Byte.Parity_Even to the correct value, 
//MCast_Byte_2 not included in ExtendedFormat 
MCast_Byte_2 = ((MCast_Byte XOR OxFF) AND 0x55) OR 
(MCast_Byte AND 0xAA) 
Calculate CRC of time correction section based on format used,, 
} 
ENDIF 


// If Time Correction messages are being sent, increment to the 
// next consumer 

IF (RR_Con_Num_Index_Pntr < Max_Consumer_Number), 
THEN 

{ 


} 
ENDIF 


RR_Con_Num_Index_Pntr = RR_Con_Num_Index_Pntr + 1, 


// Set the time stamp value 
Time_Stamp_Section.Data_Time_Stamp = Producer_Safe_Data_TS, 
IF (ExtendedFormat), 
THEN 
{ 
// check for rollover 
IF (unsigned compare(Time_Stamp_Section.Data_Time_Stamp < Last_Time_Stamp_For_Rollover)) 
THEN 
{ 
TS_Rollover_Count = TS_Rollover_Count + 1 
} 
ENDIF 
// set the seed value 
RC_Used_in_CRC = TS_Rollover_Count 
// save the time stamp 
Last_Time_Stamp_For_Rollover = Time_Stamp_Section.Data_Time_Stamp 
} 
ENDIF 
} 
END multi_cast_producer_function() 
GT LLL 
// end of multi-cast processing 
TUM 


2-2.5.1.1.1.4 Example Time Coordination Message Reception Logic 


The SafetyValidatorClient must complete the following steps for each time coordination 
message received. For single-cast and multi-cast safety connections, a Consumer_Time_Value 
is received in the time coordination message. 


FRS333 Producers shall allow Time Coordination responses to arrive during the Ping_interval, 
or Ping_Interval + 1. 
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THUMM 

//Time Coordination message reception processing 

THUMM 

// Consumer_Num equals | for single-cast 

// Consumer_Num equals the consumer the message 

// was received from for multi-cast 

TUM 

// This Logic should only be executed If Ack_Byte.Ping_Response 

// of the message is equal to 1 AND Consumer_Open[Consumer_Num-1] 

// is equal to Open. If Ack_Byte.Ping_Response is equal to0 OR 

// Consumer_Open[Consumer_Num-1]is equal to Closed, this 

// message should be ignored. 

TU 

// reject Time Coordination packets if CONSUMER_TIMESTAMP has previously been captured AND 

this is not the first time coordination message from this consumer 

IF ( (Consumer_Time_Value[Consumer_Num-1] == 

Time_Coordination_Section.Consumer_Time_Value) AND 
(Consumer_Active_Idle[Consumer_Num-1] == Active) ) 

THEN 

{ 
// the only time this would be the case is if that Time Coordination was already received 
Abort the processing of this packet. Do Not close the connection. 

} 

ENDIF 


// Capture the received time 
Producer_Rcved_Time_Value[Consumer_Num-1] = Producer_Clk_Count, 


// Perform the integrity checks 

Check the CRC of the Time Coordination Section, based on format used, 
Ack_Byte_Error = false, 

IF ((Ack_Byte parity incorrect) 

THEN 

{ 


} 
ENDIF 


IF (BaseFormat) 
THEN 
{ 


Ack_Byte_Error = true, 


/ickeck Ack_Byte_2 if BaseFormat 
IF ((Ack_Byte parity incorrect) OR (Ack_Byte_2 != 
(((Ack_Byte XOR OxFF) AND 0x55) OR (Ack_Byte AND 0xAA)))) 
THEN 
{ 
Ack_Byte_Error = true, 
} 
ELSE 
{ 
Ack_Byte_Error = false, 
} 
ENDIF 
ENDIF 
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IF ((CRC_Error based on format used) OR (Ack_Byte_Error = true) OR 

// Ensure that the Time Coordination message returned 

// with the same ping interval or the next ping interval. 

// The next ping interval is allowed for the case that a 

// multi-cast consumer connects to an existing producer. 

// If the new consumer receives its first message near the end 

// of the ping interval, the time coordination may arrive back 

// at the producer during the next ping interval. 
((Ack_Byte.Ping_Count_Reply != Ping_Count) AND 
(Ack_Byte.Ping_Count_Reply != Ping_Count-1)) OR 

// Ensure that the Time Coordination message returned 

// within the approximatley 5 second limit 

((Consumer_Active_Idle[Consumer_Num-1] == Active) AND 

(Ping_Interval_EPI_Count > 

Time_Coord_Response_EPI_Limit[Consumer_Num-1])), 


THEN 
{ 
IF (ExtendedFormat), 
THEN 
{ 
//decide whether to close the connection or not 
Increment Producer_Fault_Counter[Consumer_Num-1] 
IF (Producer_Fault_Counter[Consumer_Num-1] >= Max_Fault_Number) 
THEN 
{ 
S_Connection_Fault{Consumer_Num-1] = Faulted, 
Abort the processing of this packet. Close the connection. 
} 
ELSE 
{ 
Abort the processing of this packet. Do Not close the connection. 
} 
ENDIF 
} 
ELSE 
{ 
S_Connection_Fault[{Consumer_Num-1] = Faulted, 
Abort the processing of this packet. Close the connection. 
} 
ENDIF 
} 
ENDIF 


// at this point we know we have a good, non-redundant time coordination packet 


// Capture the received CONSUMER time 
Consumer_Time_Value[Consumer_Num-1] = 
Time_Coordination_Section.Consumer_Time_Value; 


// Determine the worst case Consumer_Time_Correction_Value based on the 
// received Time_Coordination section 
Worst_Case_Consumer_Time_Correction_Value[Consumer_Num-1] = 
Time_Coordination_Section.Consumer_Time_Value 
- Producer_Rcved_Time_Value[Consumer_Num-1] 
- Connection_Correction_Constant{Consumer_Num-1], 
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// Determine the worst case time drift since the last 

// Time Coordination information was received. This is equal to the 
// number of Ping Intervals since the last Time Coordination message 
// times the Time Drift per Ping Interval plus | for the asyncronous 
// clocks. This value will not be used until the second 

// Time_Coordination message is recived. 


Time_Drift_Since_Last_Time_Coord = 
({Ping_Int_Since_Last_Time_Coord_Msg_Count[Consumer_Num-1]+ 1} 
* Time_Drift_Per_Ping_Interval) + 1, 


// If this Time_Coordination Transport delay is greater then the 

// last Time_Coordination Transport delay by more than the appropriate 

// number of Time_Drift_Per_Ping_Intervals, then, use the previous 

// Correction value minus the appropriate number of 

// Time_Drift_Per_Ping_Intervals. This action is not taken until the 

// second Time_Coordination message is received. 

// The math for this check should be 16 bit or greater 

IF ((Consumer_Active_Idle[Consumer_Num-1] == Active) AND 

((Consumer_Time_Correction_Value[Consumer_Num-1]- 
Worst_Case_Consumer_Time_Correction_Value[Consumer_Num-1] — 

Time_Drift_Since_Last_Time_Coord) AND 0x8000 == 0)), 

THEN 

{ 

Consumer_Time_Correction_Value[Consumer_Num-1] = 

Consumer_Time_Correction_Value[Consumer_Num-1] - 

Time_Drift_Since_Last_Time_Coord, 

} 

ELSE 

{ 

Consumer_Time_Correction_Value[Consumer_Num-1] = 

Worst_Case_Consumer_Time_Correction_Value[Consumer_Num-1], 


} 
ENDIF 


// Set the flag indicating a Time_Coordination message has been received 
IF (S_Connection_Fault[Consumer_Num-1] = OK) 

THEN 

{ 

Consumer_Active_Idle[Consumer_Num-1] = Active, 


} 
ENDIF 


// Reset the Time_Coordination message timer 
Ping_Int_Since_Last_Time_Coord_Msg_Count[Consumer_Num-1] = 0, 
TUM 

// end producer time coordination information reception processing 
HUT 


2-2.6 Safety ValidatorServer Function Definition 


The Safety ValidatorServer function is the safety layer that augments a standard CIP connection 
to transmit SIL 3 data. It coordinates the reception of safety data with a peer instance of the 
Safety ValidatorClient class and delivers this data to the consuming safety application. 
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2-2.6.1 Safety Consumption 


This section describes the consumption of data and the interfaces between the application, the 
Safety ValidatorServer and the underlying link layer. 


There are two versions of safety data consumer monitoring. They are: 


e Safety ValidatorServer - Link Triggered. 
This option is appropriate for consuming applications that are synchronized to the reception 
of the data, or consuming applications that present a continuous delay from the reception of 
data. 

e Safety ValidatorServer - Application Triggered. 
This option is appropriate for consuming applications that are periodic in nature and not 
synchronized to the reception of the data. 


In both versions, FRS127 the Safety ValidatorServer shall perform the following aspects of the 
safety data monitoring: 


e Time coordination with the producer 
e Time stamp section integrity checking 
e Data integrity checking 

e Network time expectation checking 


2-2.6.1.1 Safety ValidatorServer - Link Triggered 


Figure 2-2.7 Consumer Safety Data Monitoring 
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FRS128 The Link Triggered Safety ValidatorServer shall perform all aspects of the safety 


protocol on each message received. 
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FRS129 For multi-cast, the Link Triggered Safety ValidatorServer shall also perform all aspects 
of the safety protocol on each Time_Correction section received. 


FRS130 The Safety ValidatorServer shall insure that the safety data presented to the consuming 
application has been crosschecked and that the network time expectation is being met. 


FRS131 The Link Triggered Safety ValidatorServer shall set the new data flag each time data is 
ready for consumption. 


2-2.6.1.2 Safety ValidatorServer - Application Triggered 


Figure 2-2.8 Safety ValidatorServer - Application Triggered 
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The Application Triggered Safety ValidatorServer does not fully process each message. 


FRS132 The process reception stage of the application triggered Safety ValidatorServer shall 
check the ping count for all incoming data messages. 


FRS 133 For multi-cast consumption in application triggered Safety ValidatorServers, the latest 
Time_Correction section received shall be forwarded to the consuming application. 


FRS 134 The consuming safety application shall request new data from the 
SafetyValidatorServer in order to cause the Safety ValidatorServer to complete processing of a 
message. 


For periodic applications that are not synchronized to the reception of the data, this reduces the 
processing burden, since the data section is only crosschecked (in Process Second Stage in 
Figure 2-2.8) for the safety data messages that are used. This is particularly useful for the case 
where the network EPIs are at a faster rate then the consuming application’s periodic rate. 


FRS135 The consuming application shall ensure that it gets new data at least once every 2 
seconds to ensure that the time stamp does not rollover. 
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2-2.6.2 Safety Data Reception Logic 


The safety data reception processing consists of: 


e Ping_Count check 

e Time Stamp section checking 

e Data integrity checking 

e Time stamp checking 

e Deriving Run_Idle and fault status 


The definitions of the variables used in the safety data reception logic can be found in section 
2-4.6 


The following table shows the safety data processing steps that are performed by the Link 
Triggered Safety ValidatorServer. 


Table 2-2.1 Data Reception - Link Triggered 


Single-Cast Multi-Cast 
Check Ping_Response No No 
Check Ping_Count Yes Yes 
Check Time stamp section CRC Yes Yes 
Check Run_Idle Yes Yes 
Check TBD_Bit Yes Yes 
Check Data CRCs Yes Yes 
Check Data Actual/Complement Yes Yes 
Derive Data_Time_Stamp Yes Yes 


The following table shows the safety data processing steps that shall be performed by the Link 
Triggered Safety ValidatorServer for the reception of each Time Correction section. 


Table 2-2.2 Time_Correction Reception - Link Triggered 


Multi-Cast 
Check MCast_Byte and MCast_Byte_2 Yes, if consumer_# match 
Check Time_Correction CRC Yes, if consumer_# match 
Get Time_Correction_Value Yes, if consumer_# match 
Check Multi_Cast_Active_Idle Yes, if consumer_# match 


The following table shows the safety data processing steps that are performed on each message 
reception by the application triggered Safety ValidatorServer. 
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2-2.6.2.1 


Table 2-2.3 Data Reception - Application Triggered 


Single-Cast Multi-Cast 
Check Ping Response No No 
Check Ping_Count Yes Yes 
Check Time stamp section CRC No No 
Check Run_Idle No No 
Check TBD_Bit No No 
Check Data CRCs No No 
Check Data Actual/Complement No No 
Derive Data_Time_Stamp No No 


The following table shows the safety data processing steps that shall be performed on each 
Time_Correction section reception by the application triggered Safety ValidatorServers. 


Table 2-2.4 Time_Correction Reception - Application Triggered 


Multi-Cast 
Check MCast_Byte and MCast_Byte_2 Forward message if consumer_# 
match 
Check Time_Correction CRC No 
Get Time_Correction_Value no 
Check Multi_Cast_Active_Idle No 


The following table shows the safety data processing steps that are performed by the 
application triggered Safety ValidatorServer when safety data is requested. 


Table 2-2.5 Consuming Application —- Safety Data Monitoring 


Single-Cast 


Multi-Cast 


Check Ping_Response NA 
Check Ping_Count NA NA 
Check Time stamp section CRC Yes Yes 
Check MCast_Byte and MCast_Byte_2. | NA Yes (from last time correction) 
Check Time_Correction CRC NA Yes (from last time correction) 
Get Time_Correction_Value NA Yes (from last time correction) 
Check Multi_Cast_Active_Idle NA Yes (from last time correction) 
Check Run_Idle Yes Yes 
Check TBD_Bit Yes Yes 
Check Data CRCs Yes Yes 
Check Data Actual/Complement Yes Yes 
Derive Data_Time_Stamp Yes Yes 


Ping Count Checking 


FRS142 The Safety ValidatorServer shall perform Ping_Count checking on every message . 
Ping_Count checking checks the ping count to see if it has changed. 


FRS332 If a Safety ValidatorServer detects that the ping count has changed, it shall produce a 
time coordination message within that Ping Interval or within 5 seconds, whichever is less. 
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Ping_Count checking errors should not be treated as dangerous failures. The time stamp 
section CRC does not need to be checked to perform the Ping Count checking. 


2-2.6.2.2 Data and Network Time Expectation Checking Maximum Interval 


FRS145 The data integrity shall be checked at least once every 2 seconds. 


FRS146 The Time Stamp and Network Time Expectation (NTE) shall be checked at least once 
every 2 seconds 


2-2.6.2.3 Example Cold Start Initialization 


TAMU 

// Cold start after connection establishment processing 
MUM 

// This Logic should be executed at the transition of the 
// consuming connection from closed to open. 
CELL 


S_Con_Flt_C_Out = OK, 
Init_Complete_Out = 0, 
S_Run_Idle_Out = Idle, 


Last_Ping_Count = 3, 
Time_Coordination_Count_Down = 0x0000, 


Corrected_Data_Time_Stamp = 0x0000, 
Last_Data_Time_Stamp = 0x0000, 
Last_Reved_Multi_Cast_Active_Idle = Idle, 
Last_Reved_Time_Correction_Value = 0x0000, 
Time_Correction_Ping_Interval_Count = 0x0000, 
Time_Correction_Received_Flag = 0, 
Data_Age = 0x0000, 
Max_Data_Age = 0x0000, 
IF (ExtendedFormat), 
THEN 
{ 
Consumer_Fault_Counter = 0 
RC_Used_in_CRC = 0x0000 
IF (Multi-cast), 
THEN 
{ 
Last_Time_Stamp_For_Rollover = Initial_TS from SafetyOpenResponse 
TS_Rollover_Count = Initial_Rollover_Value from SafetyOpenResponse 
) 
ENDIF 
TF (Single-cast), 
THEN 
{ 
IF (Originator) 
THEN 
{ 
Initial_TS for SafetyOpen = Consumer_Clk_Count 
Tnitial_Rollover_Value for SafetyOpen = Consumer_Clk_Count 
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+ Initial _RC_Offset 


} 
IF (Target) 
THEN 


Initial_TS for SafetyOpenResponse = Consumer_Clk_Count 
Tnitial_Rollover_Value for SafetyOpenResponse = Consumer_Clk_Count 
+ Initial_RC_Offset 


} 

TInitial_RC_Offset = Initial_RC_Offset + 1 
Last_Time_Stamp_For_Rollover = Initial_TS 
TS_Rollover_Count = Initial_Rollover_Value 


} 
ENDIF 


} 
ENDIF 


TMM 
// end, Cold start after connection establishment processing 
TAT 


2-2.6.3 Safety ValidatorServer - Link Triggered Logic 


The following three sections describe the consumer safety data reception logic for the 
Safety ValidatorServer - Link Triggered option. The term Link Triggered means that all the 
logic is executed on every reception. 


The first section describes the combined logic associated with the Safety data packet reception 
for the single-cast and multi-cast safety connection types. 


The third section describes the logic associated with the Time Correction Message reception for 
the multi-cast safety connection type. 


4 


his logic should only be executed if the connection is open with no errors. 


2-2.6.3.1 Example Combined Reception Logic - Link Triggered Logic 


The following is the required Safety ValidatorServer reception logic for the safety data packet 
reception of the single-cast or multi-cast safety connection type, for the Safety ValidatorServer 
— - Link Triggered Logic. 


Multi-cast connections shall send a Time Coordination Message (Consumer_Num - 1) 
receptions after the ping count change. 


FRS148 Multicast-consumers connecting to an existing producer shall send the 
Time_Coordination message immediately upon the first valid reception. 


TATU 
// Safety Data Consumption - link triggered logic 
MM 


// Tf the extended format is being used, we must determine a rollover value to 
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// be used when calculating CRCs before we attempt to validate the message 
// (since the rollover is part of CRC values in the message). 
IF (ExtendedFormat), 
THEN 
{ 
// For single-cast, a time_stamp other than 0 or a Run 
// indication, indicate that the Time_Coordination_Message has been 
// received by the Client and the corrected time stamp is being used. 
IF ((SingleCast) AND (Init_Complete_Out == 0) AND 
(Time_Stamp_Section.Data_Time_Stamp == 0) AND 
(Mode_Byte.Run_Idle == IDLE)), 
THEN 
{ 


} 
ELSE 


{ 


RC_Used_in_CRC = 0x0000, 


RC_Used_in_CRC = TS_Rollover_Count, 


// check for time stamp rollover 

IF (unsigned compare(Time_Stamp_Section.Data_Time_Stamp < 
Last_Time_Stamp_For_Rollover)) 

THEN 


{ 


i 
ENDIF 


RC_Used_in_CRC = RC_Used_in_CRC + 1, 


} 
ENDIF 


} 
ENDIF 


Temp_Fault_Flag = OK, 


// check for data integrity faults 

IF ((CRC Error based on format used) 
OR (Complement_Data_Section CRC != OK) 
OR (Mode_Byte.Run_Idle != not Mode_Byte.N_Run_Idle) 
OR (Mode_Byte. TBD_2_Bit != 

Mode_Byte. TBD_2_Bit Copy) 

OR (Mode_Byte.TBD_Bit != not Mode_Byte.N_TBD_Bit) 
OR (Actual_Data != not Complement_Data) [for > 2 bytes only] 
) 

THEN 

{ 


} 
ENDIF 


Temp_Fault_Flag = Faulted, 


// Set up Time_Stamp_Delta, to be used to check for out of sequence 
// messages Time_Stamp_Delta is not calculated until the EPI 
// reception after Init_Complete_Out is set to 1. 
TF(Init_Complete_Out == 0), 
THEN 
{ 

Time_Stamp_Delta = 1, 
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} 
ELSE 


{ 
Time_Stamp_Delta = Time_Stamp_Section.Data_Time_Stamp — 
Last_Data_Time_Stamp, 

} 

ENDIF 


// Take a look at the time stamp delta and determine if it indicates 
// the message was received in the right order. 
IF ((Time_Stamp_Delta < 0) OR 
(Time_Stamp_Delta > Network_Time_Expectation_Multiplier)), 
THEN 
{ 


} 
ENDIF 


Temp_Fault_Flag = Faulted, 


// Tf the extended format is being used, we can drop some packets with 
// data integrity/message validation or out of order errors. 

IF ((ExtendedFormat) AND (Temp_Fault_Flag == Faulted)), 

THEN 

{ 


increment Consumer_Fault_Counter 


// Calculate updated data age for the data in the last good packet 
TF (Init_Complete_Out) 

THEN 

{ 


} 
ENDIF 


Data_Age = Consumer_Clk_Count - Last_Corrected_Data_Time_Stamp, 


// Calculate the maximum worst case age 
IF (Data_Age > Max_Data_Age) 

THEN 

{ 


} 
ENDIF 


Max_Data_Age = Data_Age, 


// Is it OK to ignore this error? 
// It is OK if the consumer fault counter is not greater than the 
// maximum faults allowed and the updated data age from the 
// last good packet still meets our data age criteria 
// (less than the time expectation multiplier) 
IF ( 
(Consumer_Fault_Counter < Max_Fault_Number) AND 
(Data_Age <= Network_Time_Expectation_Multiplier) 
) 
THEN 
it 
Abort the processing of this packet. Do Not close the connection. 
Do not use the Data. 
Do not update Last_Corrected_Data_Time_Stamp or Last_Data_Time_Stamp 
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ELSE 
S_Con_Flt_C_Out = Faulted, 
Abort the processing of this packet. Close the connection. 
bettie 
Diet 


// execute a function that checks for ping count changes and 
// determines if it is time to produce a time coordination message 
ping_count_check_in_consumer_function(), 


Init_Complete_Out_Temp = 0, 


// execute the safety connection type specific functions 
IF (Connection_Type == Multi-cast), 
THEN 


{ 
multi_cast_consumer_function(), 


i 
ELSE 


{ 
single_cast_consumer_function(), 


) 
ENDIF 


// Tf we are using the ExtendedFormat, at this point we have a properly formatted 
// message that was received in the right order. With the extended format 
// update the rollover count and last timestamp for rollover. 
IF (ExtendedFormat), 
THEN 
{ 
// Only update the rollover count if this is a multicast connection 
// or if this is a singlecast connection that is out of the initialization 
// phase. 
IF ((Connection_Type == Multi-cast) OR 
(Init_Complete_Out_Temp == 1)), 
THEN 
{ 
// Check the timestamp value in the message to determine if a 
// rollover has occurred, and if so, update the rollover count 
// accordingly. 
IF (unsigned compare(Time_Stamp_Section.Data_Time_Stamp < 
Last_Time_Stamp_For_Rollover)) 
THEN 


TS_Rollover_Count = TS_Rollover_Count + 1, 


} 
ENDIF 


Last_Time_Stamp_For_Rollover = Time_Stamp_Section.Data_Time_Stamp, 


} 
ENDIF 


// Save the corrected data timestamp so we can recalculate a data age 
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// if the next packet has errors. 
Last_Corrected_Data_Time_Stamp = Corrected_Data_Time_Stamp, 


} 
ENDIF 


// Save Time stamp for next reception sequence check 
Last_Data_Time_Stamp = Time_Stamp_Section.Data_Time_Stamp, 


// Calculate the worst case age 

IF (Init_Complete_Out_Temp == 1), 
THEN 

{ 


} 
ENDIF 


Data_Age = Consumer_Clk_Count - Corrected_Data_Time_Stamp, 


// Calculate the maximum worst case age 
IF (Data_Age > Max_Data_Age) 

THEN 

{ 


} 
ENDIF 


Max_Data_Age = Data_Age, 


// Check for Age, Integrity, and out of sequence faults 
TF (( unsigned int_16( Data_Age > Network_Time_Expectation_Multiplier) 
AND (Init_Complete_Out_Temp == 1)) 
OR (Temp_Fault_Flag == Faulted)) 
THEN 
{ 
// The connection will be closed, the data should not be used 
S_Con_Flt_C_Out_Temp = Faulted, 
} 
ENDIF 


TUM 

// The following information is passed on to the consuming application 
// with block integrity: Safety Data,Init_Complete_Out,S_Run_Idle_Out 
// and S_Con_Flt_C_Out. 

// The time between the checking of the age of the data and passing 

// the data off to the consuming application must be protected under 

// the time_stamp check or the consuming application time checks. 
TUM 

Make Safety Data Available to Consuming Application 
Init_Complete_Out = Init_Complete_Out_Temp, 

S_Run_Idle_Out = S_Run_Idle_Out_Temp, 

S_Con_Flt_C_Out =S_Con_Flt_C_Out_Temp, 
THUMM 

// end Safety Data Consumption - link triggered logic 
TUM 
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TMU 

// Start of single-cast consumer function 
TUM 
single_cast_consumer_function() 

// For single-cast multicast, no time stamp correction is required 
Corrected_Data_Time_Stamp = Time_Stamp_Section.Data_Time_Stamp, 


// Determine the Init_Complete_Out state to be passed on to the 
// consuming application. 
// For single-cast or bi-dir, a time_stamp other than 0 or a Run 
// indication, indicate that the Time_Coordination_Message has been 
// received by the Client and the corrected time stamp is being used. 
IF ((Init_Complete_Out == 1) OR 
(Corrected_Data_Time_Stamp !=0) OR 
(Mode_Byte.Run_Idle == Run)), 
THEN 
{ 


} 
ENDIF 


Tnit_Complete_Out_Temp = 1, 


// Determine the Run_Idle indication to be passed on to the consuming 

// application. 

TF (((Mode_Byte.Run_Idle == Idle) OR (Init_Complete_Out_Temp == 0)) 
THEN 

{ 


} 
ELSE 


{ 


} 
ENDIF 


S_Run_Idle_Out_Temp = Idle, 


S_Run_Idle_Out_Temp = Run, 


END single_cast_consumer_function() 
THUMM 
// end of single-cast processing 
GLEE 


TUM 

// Start of multi-cast consumer function 
TUM 
multi_cast_consumer_function() 

// Tf multi-cast, check that a time correction message has been 

// received within the last Timeout_Multiplier.PI + 1 Ping Intervals 

IF (Time_Correction_Ping_Interval_Count > (Timeout_Multiplier.PI + 1)) 
THEN 

{ 


} 
ENDIF 


Temp_Fault_Flag = Faulted, 


// Tf multicast, add correction value to time stamp 
Corrected_Data_Time_Stamp = Time_Stamp_Section.Data_Time_Stamp + 
Last_Reved_Time_Correction_Value 
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// Determine the Init_Complete_Out state to be passed on to the 

// consuming application. 

// For multi-cast, the reception of a Time_Coorection Message, indicate 
// that data may be used. 

IF (Time_Correction_Received_Flag == 1) 

THEN 

{ 


i 

ENDIF 

// Determine the Run_Idle indication to be passed on to the consuming 

// application. 

IF ((Mode_Byte.Run_Idle == Idle) OR 
(Init_Complete_Out_Temp == 0) OR 
(Time_Correction_Received_Flag == 0) OR //used only on multi-cast 
(Last_Reved_Multi_Cast_Active_Idle==Idle))//used only on multi-cast 

THEN 


{ 


} 
ELSE 


{ 


} 

ENDIF 

end multi_cast_consumer_function() 
THUMM 
// end of multi-cast processing 
Tt 


Init_Complete_Out_Temp = 1, 


S_Run_Idle_Out_Temp = Idle, 


S_Run_Idle_Out_Temp = Run, 


CELL 
// Start of ping count check function 
TUL 
ping_count_check_in_consumer_function() 


// Check if its time to send a Time Coordination Message 
// Multi-cast connections send a Time Coordination Message 
// (Consumer_Num — 1) receptions after the ping count change. 
IF (received Mode_Byte.Ping_Count != Last_Ping_Count), 
THEN 
{ 
Time_Coordination_Count_Down = Consumer_Num, 
Increment Time_Correction_Ping_Interval_Count, 
} 
ENDIF 


// For multicast-consumers connecting to an existing producer, send 
// the Time_Coordination message immediately upon the 1“ reception. 
TF (It is the first data reception), 
THEN 
{ 
Produce Time_Coordination_Message, 
Time_Coordination_Count_Down = 0, 


t 
ENDIF 
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// Check if a ping count change has been detected and the Time 
// Coordination message has not been sent yet. 

IF (Time_Coordination_Count_Down > 0), 

THEN 

{ 


decrement Time_Coordination_Count_Down, 


// Send the Time_Coordination_message if the decremented 
// Time_Coordination_Count_Down transitions to 0 

IF (Time_Coordination_Count_Down == 0), 

THEN 

( 


} 
ENDIF 


Produce Time_Coordination_Message, 


} 
ENDIF 


// Save ping count for next reception check 
Last_Ping_Count = Mode_Byte.Ping Count, 


end ping_count_check_in_consumer_function() 
TUM 
// end of ping count check function 
MUU 


2-2.6.3.2 Example Time Correction Message Reception - Link Triggered Logic 


The following is the required Safety ValidatorServer logic associated with the Time Correction 
Message reception for the multi-cast safety connection type, for the Consumer — Link 
Triggered. 


CLL 
// Consumer processing - Time Correction Message reception 
TUM 
//Is the Time Correction message for this Consumer ? 
IF (MCast_Byte.Consumer_Num = Consumer_Num) 
// Perform integrity checks. 
THEN 
{ 
IF (Time Coordination message CRC incorrect) 
OR (MCast_Byte parity incorrect) 
// MCast_Byte_2 not included in ExtendedFormat 
OR {MCast_Byte_2 != (((MCast_Byte XOROxFF)AND0xS55) 
OR(MCast_Byte ANDOxAA))} 
OR {(MCast_Byte.Multi_Cast_Active_Idle == Idle) 
AND (Last_Reved_Multi_Cast_Active_Idle == Active) }, 
// only one transition from connection idle to active will 
// be allowed, to prevent an erroneous idle indication, 
// a transistion from active to idle will be latched into 
//a fault state 


THEN 
{ 
IF (ExtendedFormat) 
THEN 
{ 
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2-2.6.4 


{increment Consumer_Fault_Counter 
IF (Consumer_Fault_Counter < Max_Fault_Number) 
THEN 
{ 
Abort the processing of this packet. Do not close the connection, 
Do not use the Data. 
} 
ELSE 
{ 
S_Con_Flt_C_Out = Faulted, 
Abort the processing of this packet. Close the connection 
{ 
ENDIF 
} 
ELSE 


{ 
S_Con_Flt_C_Out = Faulted 


ENDIF 


// Save the Time_Correction_Value. 
Last_Reved_Time_Correction_Value = 
Time_Correction_Section.Time_Correction_Value, 


// Save the Multi_Cast_Active_Idle bit. 
Last_Reved_Multi_Cast_Active_Idle = 
MCast_Byte.Multi_Cast_Active_Idle, 


// Set the Time_Correction_Received_Flag. 
Time_Correction_Received_Flag = 1, 


// Reset the Time Correction timeout counter 
Time_Correction_Ping_Interval_Count = 0, 
ENDIF 
TAT 
// end - Time Correction Message reception 
TM 


Safety ValidatorServer - Application Triggered Logic 


For Safety ValidatorServer - Application Triggered, the same logic described above must be 
performed by the combination of the Safety ValidatorServer, but only when requested by the 
consuming application. Application Triggered implementations only process the safety packets 
when needed by the application. This implementation strategy is useful for applications that 
usually run slower than a typical EPI rate. The functions can be divided as shown in Table 2- 
2.3 and Table 2-2.5. 


The protocol processing steps shown in Table 2-2.5 only need to be performed on the messages 
used by the consuming application. 
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2-2.6.5 


Example Time Coordination Message Production Logic 


The Safety ValidatorServer must perform the following steps each time a time coordination 
message is sent. For single-cast and multi-cast safety connections, time coordination data is 
sent in the time coordination message. This logic is also described in the 
single_cast_function() of the combined production logic section. 


TUM 

//Time Coordination message production processing 
TU 

// Set the Ping_Count_Reply to the value captured at the ping request 
Ack_Byte.Ping_Count_Reply = Mode_Byte.Ping_Count, 


// Set the Ping_Response bit to 1 
Ack_Byte.Ping_Response = 1, 


// Set the Consumer_Time_Value to the Consumer clock value 
Time_Coordination_section.Consumer_Time_Value = Consumer_Clk_Count, 


// Add data integrity measures 

Set Ack_Byte.Reserved(6:4) = 0, 

Set Ack_Byte.Reserved(2) = 0, 

Set Ack_Byte.Parity_Even bit to the correct value, 

//Ack_Byte_2 not included in ExtendedFormat 

Ack_Byte_2 !=(((Ack_Byte XOR OxFF)AND 0x55)OR 
(Ack_Byte AND 0xAA)), 

Calculate CRC on Time Coordination message, 

TUM 

// end time coordination message send logic 

TUM 


CIP Connection Establishment 


This section provides the general requirements for CIP connection establishment between 
safety nodes on and between DeviceNet, EtherNet/IP or SERCOS III. Figure 2-3.1 depicts a 
conceptual view of the highly flexible interconnection variations that are supported: 


Figure 2-3.1 Conceptual Views of CIP Connections 


\ 


EtherNet/IP 
/ \ 
ControlNet f DeviceNet 
Pre a —_ 
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2-3.1 


2-3.1.1 


Overview 


This section does not attempt to provide a tutorial on every aspect of CIP, but rather a high- 
level overview of how CIP connections are established on each network and across network 
types, highlighting the features used and extensions required to support Safety Connections. 
For details on CIP connections and data formats as supported on the various network 
technologies, refer to their respective specifications. 


FRS153 All CIP Safety connections shall be established using a Forward_Open with a safety 
network segment (EtherNet/IP, SERCOS IID) or a SafetyOpen (DeviceNet) . 


There are measures for detection of both system and user errors defined. The following table 
shows the errors and the measures to detect these errors. 


Table 2-3.1 Connection Establishment Errors and Measures to Detect Errors 


hy * Measures to detect connection establishment errors 
Connection Establishment - " 
aeons User OUNID TUNID CPCRC Configuration 
Testing Verification Verification CRC ID (SCID) 
User misroutes connection x x! x 
request 
System misroutes connection x 
request 
Corrupted Forward Open x 
Corrupted or Changed 
Application Configuration 
Reconfiguration from wrong x! 
originator 


Note 1; Only applies if ownership has been established. 


Definition of the Measures Used During Connection Establishment 


System-Wide Unique "Safety Network Number" (SNN) — Uniquely identifies a network 
across all networks in the safety system. FRS154 The user safety manual shall contain an 
advisory that states “The user should assign SNN numbers for each safety network or safety 
sub-net that are unique system-wide”, or words to that effect. This number shall be defined 
uring node commissioning (i.e.: set via the Propose_TUNID/Apply_TUNID process defined 
in the SafetySupervisor if the SNCT Interface is supported). 


The Safety Network Number makes up part of the UNID. This value is a 6-octet value that 
uses the CIP DATE_AND_TIME format. 


The DATE values of | thru 11,687 decimal (January 1, 1972 thru Dec 31, 2003) are past time 
values that are reserved for Manual Setting values of the SNN. 


ie SNN may be one of two types: 


Manual Setting 
2. Software Tool Generated 


ie Type of SNN can be determined from the DATE section. 


=| 
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Table 2-3.2 SNN Date/Time Allocations 


From To From To SNN Type 
DATE DATE DATE DATE 
(Decimal) (Decimal) (Day) (Day) 
0 0 Jan 1, 1972 Jan 1, 1972 Null SNN (Illegal Value) 
1 1 Jan 2, 1972 Jan 2, 1972 Manual Setting - Backplane 
2 2 Jan 3, 1972 Jan 3, 1972 Manual Setting - ControlNet 
3 Ee) Jan 4, 1972 Jan 4, 1972 Reserved for future use 
4 4 Jan 5, 1972 Jan 5, 1972 Manual Setting — EtherNet/IP 
5 =) Jan 6, 1972 Jan 6, 1972 Manual Setting — DeviceNet 
6 6 Jan 7, 1972 Jan 7, 1972 Manual Setting - SERCOS III 
7 1460 Jan 7, 1972 Dec 31, 1975 Reserved for future use 
1461 11,687 Jan 1, 1976 Dec 31, 2003 Vendor Specific range 
11,688 65,534 Jan 1, 2004 Jun 5, 2151 Software Tool Generated 
65,535 65,535 Jun 6, 2151 Jun 6, 2151 Target indication that no SNN 
has been set 
If a software tool reads a reserved SNN Type, it shall display it as a Hex value. 


The legal Range of TIME values for the Type of SNN are listed in the following table. 


Table 2-3.3 SNN Legal Range of Time Values 


SNN Type FromTime To Time From Time To Time 
(Hex) (Hex) (Hour/Min/Sec) (Hour/Min/Sec) 
Null SNN 0x00000000 0x00000000, 00d00h00m00.000s 00d00h00m00.000s 
Manual Setting 0x00000001 0x0000270F 00d00h00m00.001s 00d00h00m09.999s 
(DATE = | thru 6) (9,999 decimal) 


Reserved for future 
use 


Software Tool 0x00000000 0x05265BFF 00d00h00m00.000s 00d23h59m59.999s 
Generated 

Target indication OxFFFFFFFF | 0xFFFFFFFF -24d20h31m23.648s | -24d20h31m23.648s 
that no SNN has 

been set 


System-Wide "Unique Node IDentifier" (UNID) — Uniquely identifies a node across all 
networks in the safety system. This value is made up of the Safety Network Number (SNN) 
and the Node Address of the device. This value is a structure consisting of the 6-byte SNN and 
a 4-byte Node Address. The 4-byte node address is sized to accommodate all forms of CIP 
network addresses. 


struct UNID 

{ 

S_SNN SNN; 

UDINT MACID; 

}s 
MACIDs smaller than 4-bytes (i.e., DeviceNet) shall be aligned to the least significant byte in 
little endian order. The unused bytes shall be zero filled. 
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Safety Function — The UNID is used to uniquely identify originators and/or targets during 
the connection establishment process 


Other uses of UNID: 
TUNID = Target's Unique Network Identifier 

Safety Function — Identifies the target in the SafetyOpen 
OUNID = Originator's Unique Network Identifier 

Safety Function — Identifies the originator in the SafetyOpen 
OCPUNID = Output Connection Owning UNID 


Safety Function — Identifies the owner of the output connection in the target, this shall be 
equal to the OUNID in normal operation 


CFUNID = Configuration Owning UNID 


Safety Function — Identifies the owner of the safety configuration in the target, this shall be 
equal to the OUNID in normal operation 


Producer Identifier (PID) - Identifies the producer of the runtime data and Time Correction 
data. 


FRS155 The Producer Identifier (PID) shall be used as an initial seed value in the CRCs in the 
runtime protocol. 


FRS156 The Consumer shall obtain the Producer Identifier from either the SafetyOpen or 


SafetyOpen response (depending upon originator) and use the value as an initial seed in 
runtime checking the safety CRCs. 


The value of the PID is Vendor ID + Device Serial Number + CIP Connection Serial Number. 


Safety Function — The PID is used to ensure the correct routing of the produced/safety 
connection data and Time Correction data. 


Consumer Identifier (CID) — Identifies the producer of the Time Coordination message. 


FRS330 The Consumer Identifier (CID) shall be used as an initial seed value in the CRC in the 
Time Coordination message. 


FRS331 The Producer shall obtain the Consumer Identifier from either the SafetyOpen or the 
SafetyOpen Response (depending upon originator) and use the value as an initial seed in 


runtime checking the safety CRCs . 


The value of the CID is Vendor ID + Device Serial Number + CIP Connection Serial Number. 
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Safety Function — The CID is used to ensure the correct routing of the Time Coordination 
data. 


Connection Parameters CRC (CPCRC) - This is a safety related CRC covering the CIP 
connection establishment data in the Safety Open. This CRC will also cover the additional 
parameters required by the safety protocol. The CRC used for the CPCRC is CRC-S4 and is 
defined in Appendix E. 


Safety Function — The CPCRC is used to ensure the integrity of the connection data 
contained within the Safety Open. 


Safety Configuration CRC (SCCRC) — This is a CRC that covers the device configuration 
data that is contained in a Safety Open. The parameters covered by the CPCRC are not 
covered by the SCCRC. The CRC used for the SCCRC is CRC-S4 and is defined in Appendix 
E. 


FRS110 The Safety Configuration Data CRC (SCCRC) shall be calculated over the entire 
application data section that is sent to the device being configured by the tool. 


FRS158 The SCCRC itself shall be included in the calculation of the CPCRC 


Safety Function — The SCCRC is used to ensure configuration data integrity while being 
transferred and to ensure configuration data integrity in storage. 


Safety Configuration Time Stamp (SCTS) — This is a safety related signature that identifies 
the revision of the device configuration contained in either a Safety Open or in a safety device. 


FRS161 The SCTS shall be a Time/Date stamp marking the Time & Date of the configuration 
creation or change. 


FRS160 The SCTS parameter in the Safety Open shall be included in the calculation of the 
CPCRC. 


FRS162 The configuration software shall follow the CIP defined Date and Time format (IEC 
1131-3) for setting the signature. 


Safety Function — The SCTS is used to ensure the identity of the safety application data. 


Safety Configuration Identifier (SCID) — The SCID is a combination of the SCCRC and the 
SCTS. The SCTS and SCCRC together serve to uniquely identify a configuration to the user 
and originator. 


FRS163 The SCID = 0 in a Type 2b SafetyOpen shall have special meaning to indicate that the 
SCID shall not be checked by a target before accepting the connection. 


This special SCID value allows originators who are not concerned about the configuration of a 
device to make connections without knowing the SCID value. 


FRS103 The safety manual shall contain user instructions that state “If you choose to configure 
safety connections with an SCID=0, you are responsible for ensuring that originators and 
targets have the correct configurations”, or similar equivalent wording. 
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2-3.1.2 


Initial Time Stamp - When the Extended safety message format is being used, the Extended 
format safety segment and Extended SafetyOpen Response is used during connection 
establishment. Depending on the type of connection (refer to Section 2-2.4), the Initial Time 
Stamp is either sent in SafetyOpen or in the SafetyOpen Response. The Initial Time Stamp 
value is used to set up an initial time stamp parameter that is used to detect Time Stamp 
rollovers. 


Initial Rollover Value — When the Extended safety message format is being used, the 
Extended format safety segment and Extended SafetyOpen Response is used during connection 
establishment. Depending on the type of connection (refer to Section 2-2.4), the Initial Time 
Stamp is either sent in SafetyOpen or in the SafetyOpen Response. The Initial Rollover Value 
is used to set up the initial Rollover count parameter at the consumer. This value is included in 
the CRC calculations for the data packets. If the producer and consumer don’t use the same 
value, the consumer CRC checks will fail. This feature provides additional detection capability 
for inserted messages and out-of-sequence packets. 


Originator-Target Relationship Validation 


In the CIP framework, nodes are either originators (nodes that request connections) or targets 
(nodes that receive connection requests). Controllers and monitors are typically the connection 
originators. I/O modules (as well as other controllers or monitors) are typically the targets. 
Targets may support more than one application connection point. 


Consider the system depicted in Figure 2-3.2. For the purposes of illustration, assume that all 
targets are the exact same. 


Figure 2-3.2 Target Ownership 


Nodes Owned by Originator A ( Nodes Owned by Originator B 


Originator A Originator B 


Bridge/ 


Target 1 Target 2 Target 3 Target 4 


SSS 


(Dotted lines represent logical relationships/ 
connections; solid lines are physical connections) 
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2-3.1.2.1 


2-3.1.2.2 


2-3.1.2.3 


Use of standard bridges/routers and standard lower-layer protocol stacks within the end-nodes 
offers the opportunity for additional errors that require protection measures that are more 
stringent than those applied in standard CIP connection establishment. For instance, the 
bridge/router could mis-direct (e.g. corrupt the destination MACID of) a connection request 
from originator A intended for Target 1 to Target 2, 3, or 4 instead. Or the source of the error 
could be the user mis-configuring originator B to connect to Target 1 while originator A is off- 
line and Target 1 is powered. Without a second level of comparison above the identical 
electronic key, the connection from originator B to Target | would be allowed; at which point 
originator B’s application could place Target 1 (assuming it’s an output device) into an 
incorrect operational state with respect to originator A’s commissioned application. 


Detection of Mis-routed Connection Requests 


All safety open requests will contain the UNID of the target device. Upon the receipt of a 
safety open the target must compare the SafetyOpen target UNID (TUNID) with its own 
UNID. 


FRS164 If the TUNID to UNID comparison is successful than the SafetyOpen destination is 
deemed to be correct and processing shall continue. 


SafetyOpen Processing Types 


There are two ways of processing the SafetyOpen: 


e Destination, Ownership, Configuration data processing and SCID checking 
e Destination, Ownership and SCID Checking (Optional) 


Figure 2-3.3 SafetyOpen Types 


Type 1 SafetyOpen(TUNID, OUNID, CPCRC, SCID, data, DataCRC) 


Type 2 SafetyOpen(TUNID, OUNID, CPCRC, SCID) 


Originator a Target 


Ownership Management 


There are two methods of establishing configuration and/or connection ownership, through the 
configuration tools or from the SafetyOpen. The tool can set the mode to be tool configuration 
only or originator configuration. 


FRS165 Any attempts to reconfigure a device via the SafetyOpen shall be rejected if the tool 
only configuration mode is selected. 
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If the originator configured mode is used, the OUNID of the selected originator can be set by 
the software tool during target device commissioning for added security. Figure 2-3.4 shows 
the ownership sates the methods of transitioning from ownership state to another ownership 
state. 


Figure 2-3.4 Connection Ownership State Chart 


Initial Power Turn On —~ 


Reset from any mode 
| 


a Accept ig 


First originator cone Ownership i 
/ ¥ Tool Set Mode = Too! Owned 
) \ 
/ » BN 


Y 
// Tool resets 


/ originator UNID \ 
/ \.. Tool sets Mode = 


\ Originator Owned \ 
x / 7 
No Originator 
Ownership 
7 Tool sets 
Originator Owned <— originator UNID 
Tool sets Mode = 
Tool Owned. 


FRS166 To establish ownership of the configuration (and the connection in outputs), in targets 
the OUNID of the originating device shall be passed to the target in the SafetyOpen service. 


FRS167 The OUNID of the originating device shall be stored in non-volatile storage with the 
configuration to which it is associated. 


FRS168 Output devices shall store the OUNID associated with safety outputs to prevent other 
originators from hijacking outputs inadvertently. Keeping the originator OUNID associated 
with the configuration will allow multiple devices to connect to an input device and still 
maintain configuration ownership. Figure 2-3.5 shows the mapping of the safety open UNIDS 
to the target device originator ownership locations. 
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The CIP connection objects are the entities that reconcile the inherent differences between the 
capabilities and services provided by the underlying networks, exchanging SIL 3 data with the 
application objects above. For instance, DeviceNet physical layer (i.e. CAN) data frames are 
limited to a maximum of 8 bytes each. The CIP connection object in a DeviceNet node 
transports I/O packets larger than 8 bytes via DeviceNet’s I/O fragmentation protocol; where as 
on the higher-capacity CIP networks like EtherNet/IP, the maximum CIP connection size of 

511 bytes fits into one physical layer data frame. Once a safety connection is established, the 
CIP safety application layer exchanges safety data with the safety connection objects’. 


The safety protocol has been designed to enable end-to-end transport of the safety data without 
requiring specific knowledge of the safety protocol within or SIL 3 certification of intermediate 
devices. Figure 2-3.7 depicts an end-to-end connection between a safety node on DeviceNet 
and a safety node on ControlNet routed across an EtherNet/IP network. The safety connection 
endpoints enable the application level peers to share SIL 3 data. 


Figure 2-3.7 End-to-End Routing Example 


CIP Safety CIP Safety 
App Objects App Objects 
CIP Safety cIP cIP CIP Safety 
Connection Routing Routing Connection 


DeviceNet_ Ethernet I ControINet = 


| Safety specific functionality; implementation requires certification 


Safety connection establishment is dynamic on every network. EtherNet/IP originators employ 
the Forward_Open service of the connection manager object. The connection path of a 
Forward_Open service’s data includes a safety network segment for the end node. This safety 
network segment informs the recipient that a connection object capable of supporting a safety 
connection must be available in order to accept the request. It also includes data used to 
specify Connection Object attributes related to its safety behavior (e.g. expectation timers). 


FRS169 DeviceNet originators shall use the connection manager Forward_Open service (with 
“Safety” Network Segment extension) when the target is not on the local network segment. 
This case is also referred to as an off-link connection. However, FRS170 DeviceNet 
originators shall use the Connection Object’s Safety Open request for local targets. This 
differentiation is required since DeviceNet Devices do not support the connection manager 
object. DeviceNet routers/bridges do, however, support the connection manager object. 


FRS172 On DeviceNet, the originator shall establish an explicit messaging connection with the 
router or end-node to deliver the Forward_Open or SafetyOpen service requests. The other 
CIP networks (typically) deliver the Forward_Open to the UCMM without a connection. 


For detailed examples of establishing connections across different CIP networks, refer to 
Chapter 10 — Bridging and Routing. 


> Note that standard application objects may consume safety data for standard application use. 
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2-3.1.3.1 


2-4 


2-4.1 


Basic Facts for Connection Establishment 
The basic facts for safety connection establishment are listed below: 


e SafetyOpen is a service defined in the Connection Object 
e An explicit messaging connection is required with a path that targets the Connection 

object 

e ForwardOpen is a service defined in the Connection Manager object 
¢ On CIP networks, this is an unconnected message with a path that targets the Connection 

Manager object 
e When originating from a DeviceNet originator, an explicit messaging connection is 
required with a path that targets the Connection Manager object 

© One additional set of connection parameters are required in the SafetyOpen to define the 3 
connection point in DeviceNet nodes when the connection type is Multi-cast. These 
parameters are contained in the Safety Segment. 

e A null application path is defined to mean either that a connection has no application data, 
or the SafetyOpen contains no configuration data. Each safety module vendor shall define a 
null path that is appropriate for their device. A null path shall always use a full path 
reference (i.e. 20 04 24 [vendor specific instance]). For EDS-based devices, the selected 
null instance shall be disclosed with an entry in the connection manager section of the EDS 
file (refer to Chapter 7). 

¢ The application path for the Time Coordination connection shall always be a null path. 

e Type 2 SafetyOpens (no configuration data) shall include a null application path for the 
configuration path. 

e There is no path required for the Time Correction connection 

¢ The extra parameters of the 3 connection point are named and have values as follows: 

e Time Correction RPI 

¢ Time Correction Network Connection ID 

© Connection Type = Multi-cast 

e Priority = High Priority 

e Fixed/Variable = Fixed 

e Connection Size = 6 (fixed Time Correction size) 

e The Time Correction Network Connection ID is not part of the CPCRC. 

e The standard ODT and T€O connection sizes shall always reflect the 2-connection size for 
each. In other words, the connection that has the Data and Time Correction packets 
concatenated will have a size that reflects this combination. It will be the responsibility of 
bridges and the DeviceNet nodes to calculate the appropriate sizes for the connection 
resources on DeviceNet (this is made easier in that the size of the 3" connection point, 
provided in the SafetyOpen message, can be added or subtracted). 


Safety Message Data Definitions 


Mode Byte 


This section defines the data names and ranges for the Mode Byte 
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2-4.1.1 


2-4.1.2 


2-4.1.3 


2-4.1.4 


2-4.1.5 


2-4.1.6 


2-4.1.7 


2-4.2 


2-4,.2.1 


Mode_Byte.Run_Idle 


FRS179 The Run_Idle bit value of 0 shall indicate Idle, and the Run_Idle bit value of 1 shall 
indicate Run . 


FRS180 For single-cast connections, the Run_Idle bit shall be set to Idle if the producing 
application is Idle or if the producer is waiting for Time Coordination Message information to 
be received at the initiation of data production. 


FRS181 If Time Coordination Message information has been received; the Run_Idle bit shall 
be set to the Run_Idle status indicated by the producing application. 


FRS182 For multi-cast connections, the Run_Idle bit shall be set to the Run_Idle status 
indicated by the producing application. 
Mode_Byte.N_Run_Idle 


FRS183 The N_Run_Idle complement bit shall always be the complement of the Run_Idle bit . 


Mode_Byte. TBD_2_Bit 


ie Mode_Byte Reserved TBD_2_bit shall be set to 0 by the producer 


Mode_Byte.TBD_2_Copy 


“he TBD_2_Copy bit shall always equal to the TBD_2 bit. 


Mode_Byte.Ping_Count 
The Ping _Count is used by the consumer to know when it should send a Time Coordination 
Message. 


Mode_Byte.TBD_Bit 


The Mode_Byte Reserved TBD_bit shall be set to 0 by the producer. 


FRS190 The Reserved bits shall be ignored by the consumer except for CRC checking and 
Actual/Complement checking of the TBD_Bit/N_TBD_Bit pair. 


Mode_Byte.N_TBD_Bit 


FRS191 The N_TBD_Bit complement bit shall always be the complement of the TBD_Bit . 


Time Stamp Section 


Time_Stamp_Section.Data_Time_Stamp 


The Data_Time_Stamp is the time that the Data was sampled for this production. 
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2-4.3 


2-4.3.1 


2-4.3.2 


2-4.3.3 


2-4.3.4 


2-4.4 


2-4.4.1 


For single-cast, the Data_Time_Stamp is relative to the timer that is on the consumer. For 
multi-cast, the Data_Time_Stamp is relative to the timer that is on the producer. 


The Data_Time_Stamp is always in 128 uSec increments. 


Time Coordination Message 


Ack_Byte.Ping_Response Bit 


The Ping_Response bit shall indicate that a ping response is being sent on this data production 
from the safety data consumer on this node. 


FRS195 If the Ping Response bit is 1, it shall indicate that the Consumer_Time_Value, and 
Ping_Count_Reply, are valid on this production . 


FRS196 If the Ping_Response bit is 0, it shall indicate that the Consumer_Time_Value, and 
Ping_Count_Reply, are not valid on this production and should be ignored. 


Ack_Byte.Consumer_Time_Value 


¢ Consumer_Time_Value shall be the safety data consumer’s clock value at the time that the 
message is sent. 


[he Consumer Time Value is used to derive the Data_Time_Stamp for the other directions data 
production (see FRS18, FRS61, FRS72). 


Ack_Byte.Ping_Count_Reply 


ie Ping_Count_Reply is used by each consumer to indicate the ping request that is being 
responded to (See FRSS5S). 


e Ping_Count_Reply is equal to the value of the Ping _Count that is being responded to (see 
FRSS55). 
Ack_Byte.Time Coordination Reserved bits 


FRS203 The Time Coordination Reserved bits shall be set to 0 by the consumer. 


FRS204 The Reserved bits shall be ignored by the producer except for CRC and Ack_Byte_2 
checking. 


Time Correction Message 


Mcast_Byte.Consumer_# 


FRS205 For multi-cast produced data the Multi_Cast_Active_Idle, and 
Consumer_Time_Correction_Value shall be directed to the consumer indicated by the 
Consumer_# field of the message. 
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2-4.4,.2 


2-4.4.3 


2-4.4.4 


2-4.5 


2-4.5.1 


The Consumer_# points to a specific consumer (1 through 15). 


FRS206 The Multi_Cast_Active_Idle, and the Consumer_Time_Correction_Value shall be 
applied by the consumer indicated by the Consumer_#. 


A Consumer_# of 0 should be used to indicate Multi_Cast_Active_Idle, and the 
Consumer_Time_Correction_Value are not being transferred if needed. 
Time_Correction_Section.Consumer_Time_Correction_Value 


The Consumer_Time_Correction_Value is used by the multi-cast consumer to correct the 
Producer_Time_Stamp so the resultant time stamp is relative to the consumers’ clock (see 
FRS61). 


Mcast_Byte.Multi_Cast_Active_Idle 


FRS209 The Multi_Cast_Active_Idle bit value of 0 shall indicate Idle, and the 
Multi_Cast_Active_Idle bit value of 1 shall indicate Active. 


FRS210 Once the Multi_Cast_Active_Idle bit has been set to Active after 1st data production, 
this bit shall not be set back to idle until the safety connection is re-initialized . 


FRS211 If the consumer sees the Multi-Cast_Active_Idle bit transition from Active to Idle, it 
shall close the connection if the base format is used. If the Extended Format is used and the 
Max_Fault_Count has not been reached, the packet will be dropped, otherwise the connection 
will be closed. 


For multi-cast connections, the Run_Idle bit of the Mode_Byte shall be set to the Run_Idle 
status indicated by the producing application (see FRS182). 


The consumer will need to look at both the Run_Idle bit and the Multi_Cast_Active_Idle bit. 


Mcast_Byte.Time Correction Reserved Bits 

FRS215 The Time Correction Reserved bits shall be set to 0 by the producer . 

FRS216 The Reserved bits shall be ignored by the consumer except for CRC checking and 
MC_Byte_2 checking . 

Safety Data Production 


This section describes the variables used in the production of safety data. 


Producing Connection Status 


FRS217 The producer connection status shall be determined by the combination of the 
S_Connection_Fault and the Consumer_Active_Idle flags (Refer to Table 2-4.1) , 
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2-4.5.1.1 


2-4.5.1.2 


Table 2-4.1 Producer Connection Status Determination 


S_Connection_Fault Consumer_Active_Idle Producer Comment 
Connection Status 
Fault Don’t Care Status= Faulted. Restart will be required 
OK Idle Status=Idle The safety connection has 
not been activated 
OK Active Status=Active The safety connection is 
active 


Consumer_Open 


FRS322 For Safety Data producers, Consumer_Open from the Validator Connection 
Establishment Engine to the Run Time Validator shall be provided to indicate whether or not a 
particular consumer of the produced data has an active open connection. 


FRS323 If the producer is multi-cast, Consumer_Open shall exist for each multi-cast consumer, 
through Max_Consumer_Number (indexed from 0 to Max_Consumer_Number - 1). 


The Consumer_Open values are OPEN or CLOSED. 


FRS324 The Consumer_Open indication shall act as an enable to the Run Time Validator on a 
connection by connection basis. After successful connection establishment, Consumer_Open 
flags shall transition from Closed to Open. 


FRS326 The Validator Connection Establishment engine shall provide an array of consumer 
connection status resources for multi-cast producers that shall be allocated when a consumer 
makes a connection. 


FRS327 The consumer numbers allocated to a Run-time validator shall be the number sent to 
the consumer in the connection establishment reply. (refer to 2-4.4.1) 


The consumer connection numbers can be treated as an allocation pool that can be re-used and 
re-allocated as needed. 


FRS325 The Validator Connection Establishment Engine shall ensure that the Consumer_Open 
resource for any allocated consumer number is set to Closed for a minimum time of 
(Timeout_Multiplier.PI +2) * Ping Interval prior to re-allocating that Consumer number to 
another connection. This is to ensure that any previously established connections have timed 
out prior to allocating the number to a new connection. 


In other words, if the Validator Connection Establishment Engine sees S_Connection_Fault set, 
it should set Consumer_Open to CLOSE for a minimum of (Timeout_Multiplier.PI +2) * Ping 
Interval or optionally until that same consumer tries to re-establish the same connection. 


Application_Run_Idle 


FRS218 If the producing application is actively controlling data the Run_Idle indication shall 
indicate Run. If the producing application is not actively controlling the data and the data 
should be put in the safety state, the Run_Idle indication shall indicate Idle. 
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2-4.5.1.3 


2-4.5.1.4 


2-4,.5.2 


2-4.5.2.1 


Consumer_Active_Idle [per consumer] 


Consumer_Active_Idle is a run time flag to indicating if valid Time Coordination Message 
information has been received for this consumer. 


FRS219 If a safety data producer is producing data and valid Time Coordination information 
has been received without errors the Consumer_Active_Idle flag shall be equal to Active, 
otherwise it will be Idle. 


FRS220 For multi-cast producers, a Consumer_Active_Idle flag shall exist for each multi-cast 
consumer, numbered 1 through Max_Consumer_Number. 


The Consumer_Active_Idle values are Idle and Active. 
FRS221 At connection establishment, all Consumer_Active_Idle flags shall be initialized to 
Idle. 

S_Connection_Fault [per consumer] 


S_Connection_Fault is a run time flag that indicates whether the safety connection to the 
consumer is OK or Faulted. 


FRS222 An S_Connection_Fault indication of Fault, shall indicate that the producer has 
detected a problem with the safety connection to this consumer or the consumer has indicated 
an error back to the producer. 


FRS223 If the safety data producer has received invalid Time Coordination information, or a 
Time Coordination information timeout, the S_Connection_Fault flag shall be equal to Fault, 
otherwise it will be OK. 


FRS224 For multi-cast producers, a S_Connection_Fault flag shall exists for each multi-cast 
consumer, numbered 1 through Max_Consumer_Number. 


The S_Connection_Fault values are OK and Faulted. 


FRS225 At connection establishment, all S_Connection_Fault variables shall be initialized to 
OK. 
Producer Input Static Variables 


Producer input static variables are the configuration time parameters that define the operation 
of the safety protocol producer. 


EPI 
EPI is the expected packet interval. Safety data shall be produced at a rate not exceeding the 
EPI. The EPI is expressed as an integer value in uSec. The legal range of values is from 100 to 


1,000,000 uSec. 


For all safety connections, the producer and all consumers shall all have the same EPI. 
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2-4.5.2.2 


2-4.5.2.3 


2-4.5.2.4 


Timeout_Multiplier [per consumer] 


The Timeout_Multiplier indicates the number of data production retries to use in the 
connection failure detection equations. 


The Base Format limited the Timeout_Multiplier parameter values from 1 to 4. For the Base 
Format, the Timeout_Multiplier value was used for two purposes. They are: 


1) To calculate the Network Time Expectation. 


2) To determine the number of ping intervals to wait without Time_Coordination or Time 
Correction before declaring a connection fault. 

The ExtendedFormat allows a larger Timeout_Multiplier parameter value to be used to 
calculate the Network Time Expectation, but the value used to determine the number of ping 
intervals to wait without Time_Coordination or Time Correction before declaring a connection 
fault is still limited to a maximum value of 4. The ExtendedFormat allows the 
Timeout_Multiplier parameter value to be any value from 1 to 255. 
Throughout this document “Timeout_Multiplier” will refer to the Timeout_Multiplier 
parameter value. “Timeout_Multiplier.PI” will refer to the value that is derived from 
“Timeout_Multiplier” to determine the number of Ping Intervals to wait without 
Time_Coordination or Time Correction before declaring a connection fault. 


FRS374 For the Base Format, Timeout_Multiplier.PI shall be equal to the Timeout_Multiplier. 
For the ExtendedFormat, Timeout_Multiplier.PI shall be equal to the smaller of 
Timeout_Multiplier or 4, whichever is lower. 


FRS229 The Timeout_Multiplier shall be used to determine how many ping intervals 
(Timeout_Multiplier.PI + 2) a producer will wait before faulting a consumer who has failed to 
send a Time Coordination response to a Ping request . 


FRS230 The legal range of the base format Timeout_Multiplier values shall be 1, 2, 3, or 4. 
The legal range of the Extended Format Timeout_Multiplier value shall be 1 to 255 so long as 
the Network Time Expectation value does not exceed 5.8 seconds. 


For any producer, each consumer may have a different Timeout_Multiplier. 


Connection_Type 


The Connection_Type specifies whether the connection is single-cast or multi-cast. 


FRS231 For any producer, each producer connection and the corresponding consumer 
connection(s) shall be of the same Connection Type. 
Ping_Interval_EPI_Multiplier 


Ping_Interval_EPI_Multiplier is the number that defines the Ping_Count_Interval for a 
particular connection. 
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FRS232 The Ping_Count_Interval shall be equal to the EPI times the 
Ping_Interval_EPI_Multiplier. 


FRS233 The Ping_Count_Interval shal 
will be requested and sent. 


define the rate at which Time Coordination Messages 


FRS234 The Ping_Count_Interval shall define the rate at which Time Correction sections are 


sent to each consumer. 


FRS235 A legal Ping_Interval_EPI_Multiplier shall have a minimum value determined from 
the equation Max_Consumer Number* Timeout_Multiplier.PI +15, and a maximum less than 
1000. The default values shall be 100 for Multi-cast and 19 for Single Cast 


The Ping_Interval_EPI_Multiplier should be set large enough to allow the ping request to be 
recognized by the server(s), to send the Time Coordination section(s), and all 
Time_Coordination section(s) to arrive and be processed by the client. All these steps must 


occur before the Ping_Interval time ex 


FRS237 All Time_Correction sections 


ires. 


shall be sent out by the client within the Ping_Interval. 


FRS318 The Ping_Interval_EPI_Multi 


plier shall be set small enough to ensure that the 


Ping_Count_Interval is less than or equal to 100 seconds. 


A ping count interval of greater than 100 seconds may contribute greater than .5 seconds to the 
clock drift, depending upon the Timeout_Multiplier.PI for that connection. To prevent clock 
size wrap around, .5 seconds has been set at the maximum value that can be allocated to clock 


drift. 


The following variables will be used to calculate the Ping_Interval_EPI_Multiplier. 


C_TO_S_Delay_Multiplier equals the time as a multip! 
the time for message initiation, transport delay, and rece 


ier of the EPI time that is equal to 
tion processing delay of the Data 


Message or the Time_Correction Message from the client to the server. 


S_TO_C_Delay_Multiplier equals the time as a multip 


ier of the EPI time that is equal to 


the time for message initiation, transport delay, and reception processing delay of the 


Time_Coordination Message from the server to the client. 


Ping_Reved_TO_Time_Coord_Sent_Multiplier equal 
time that is allowed from the time that the EPI reception 
the Time Coordination message until the message shoul 
Time_Coord_Reved_TO_Time_Coord_Processed_M 


t. 

s the time as a multiplier of the EPI 

that should trigger the sending of 
be sent. 


ultiplier equals the time as a 


multiplier of the EPI time that is allowed from the time t 


at the Time Coordination message 


is received until the Time Coordination message is processed. 


For a single network it is reasonable to expect that C_TO_S_| 


S_TO_C_Delay_Multiplier are less than 2 times the EPI. 


For a bridged network depending upon the number of hops, 
C_TO_S_Delay_Multiplier and S_TO_C_Delay_Multiplier 
will be used as the minimum value for C_TO_S_Delay_Mu 


Delay_Multiplier and 


it is reasonable to expect that 
are less than 4 times the EPI. 4 
Itiplier and 


S_TO_C_Delay_Multiplier when calculating the minimum value for 


Ping_Interval_EPI_Multiplier. 
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The C_TO_S_Delay_Multiplier and S_TO_C_Delay_Multiplier EPI multipliers should not 
have to consider messages being lost on the network. The Timeout_Multiplier will account for 
lost messages. 


Ping_Reved_TO_Time_Coord_Sent_Multiplier should be less than 3 times the EPI. 


Time_Coord_Rcved_TO_Time_Coord_Processed_Multiplier should be less than 3 times the 
EPI. 


The equation to determine the minimum Ping_Interval_EPI_Multiplier is: 
[{the maximum Timeout_Multiplier.PI (C#) for all consumers} * Max_Consumer_Num] + 
C_TO_S_Delay_Multiplier + S_TO_C_Delay_Multiplier + 
Ping_Rcved_TO_Time_Coord_Sent_Multiplier + 
Time_Coord_Rcved_TO_Time_Coord_Processed_Multiplier + 1 
where C# = Consumer_Number 
Using 4 as the constant used for C_TO_S_Delay_Multiplier and S_TO_C_Delay_Multiplier 
and 3 as the constant used for Ping _Rcved_TO_Time_Coord_Sent_Multiplier and 
Time_Coord_Rceved_TO_Time_Coord_Processed_Multiplier: 
FRS239 The Ping_Interval_EPI_Multiplier shall be greater than or equal to: 

[{the Max Timeout_Multiplier.PI (C#) for all consumers} * Max_Consumer_Num] + 15 
This relationship will be relied upon by the producer when sending Time Correction messages. 
For C_TO_S_Delay_Multiplier and S_TO_C_Delay_Multiplier values greater than 4 , and 
Ping_Rcved_TO_Time_Coord_Sent_Multiplier and 
Time_Coord_Reved_TO_Time_Coord_Processed_Multiplier greater than 3, the 
Ping_Interval_EPI_Multiplier must be increased accordingly. 


The Ping Interval_EPI_Multiplier must be less than: 100 Sec / EPI. 


The Ping_Interval_EPI_Multiplier range of 75 to 100 will meet the restrictions defined above 
for all legal values defined below: 


a) EPI, .0001 to 1 Sec 

b) Timeout_Multiplier.PI, 1 to 4 

c) Max_Consumer_Num, | to 15 

d) C_TO_S_Delay_Multiplier and S_TO_C_Delay_Multiplier, 1 to 4. 

e) Ping_Reved_TO_Time_Coord_Sent_Multiplier and 
Time_Coord_Reved_TO_Time_Coord_Processed_Multiplier, 1 to 3 


For any producer, the producer and all consumers must have the same 
Ping_Interval_EPI_Multiplier. 
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2-4.5.2.5 


2-4.5.2.6 


2-4.5.3 


2-4.5.3.1 


Max_Consumer_Number 
Max_Consumer_Number is the maximum number of consumers that may be configured. 
FRS241 If the connection type is single-cast, the Max_Consumer_Number shall be equal to 1. 


FRS242 For multi-cast connections, the legal range of Max_Consumer_Number values shall 
be from | through 15. 


For any producer, the producer and all consumers must have the same 
Max_Consumer_Number. 


Time_Coord_Msg_Min_Miultiplier [per consumer] 


Time_Coord_Msg_Min_Multiplier is the minimum number of 128 uSec increments it could 
take for a Time Coordination Message to traverse from the consumer to the producer. A value 
other than 0 for this variable will allow the time stamp to be more accurate. 


FRS243 The default for the Time_Coord_Msg_Min_Multiplier shall be 0, and the legal range 
values shall be from 0 through 7813, which equates to 0 through | Sec . 


° 


This is the minimum number of 128 uSec increments it could take: 
From: 


The consumer capturing Consumer_Time_Value from the Consumer_Clk_Count for the Time 
Coordination Message, 


To: 


The producer capturing the Producer_Reved_Time_Value upon reception of the Time 
Coordination Message 


For any producer, each consumer may have a different Time_Coord_Msg_Min_Multiplier. 


Producer Connection Derived Static Variables 

These static variables are derived from the input static variables. These static variables are 

derived at configuration time and are used during producer processing. 
Time_Drift_Per_Ping_Interval [per consumer] 


The Time_Drift_Per_Ping_Interval is a value in 128 uSec increments that represents the worst- 
case time drift due to crystal inaccuracy during one Ping Interval. 


FRS244 The clocks in safety devices shall be accurate to within 0.02% (0.0002) . Considering 
positive and negative drift the clocks will remain within 0.0002 *2 of each other or 0.0004 
(.04%). 


The legal range of values is from | through 313, since the Ping Interval is limited to 100 
seconds (100,000,000 uSec). 
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2-4.5.3.2 


The Time_Drift_Per_Ping_Interval calculation is done with time references in uSeconds (EPI 
is the EPI in uSecond units). The Time_Drift_Per_Ping_Interval calculation is done in 32 bit 
integer math with the result being a 16 bit integer. The divide by 320000 factor in the 
Time_Drift_Per_Ping_Interval calculation is equivalent to multiplying by the worst case clock 
drift of .0004 and dividing by 128 uSeconds. 


Time_Drift_Per_Ping_Interval (C#) 
= Roundup [EPI * Ping_Interval_EPI_Multiplier / 320000] 
OR | whichever is greater. 
where C# = Consumer_Number 
Example: if EPI = 8000us and Ping_Interval_EPI_Multiplier = 100 


Time_Drift_Per_Ping_Interval(C#) = 3 (384 us) 


Connection_Correction_Constant [per consumer] 
Connection_Correction_Constant is a value in 128 uSec increments that is subtracted from the 
time stamp to represent the worst case error due to: 


1. Time drift 

2. The asynchronous nature of the producer and consumer clocks 

3. The minimum time for the Time Coordination Message to traverse from the consumer to 
the producer 


Connection_Correction_Constant [C#] = 

Time_Drift_Constant + 1 - Time_Coord_Msg_Min_Multiplier [C#] 

where C# = Consumer_Number 
Note that the Time_Drift_Constant (which is part of the Connection_Correction_Constant 
calculation) is a value in 128 uSec increments that is subtracted from the time stamp to 
represent the worst-case time drift due to crystal inaccuracy. The producer and consumer 
clocks must be accurate to within 0.02% (0.0002). Considering positive and negative drift the 
clocks will remain within 0.0002 *2 of each other or 0.0004 (.04%). 


The legal range of values for the Time_Drift_Constant is from 1 through 1563. 


The Time_Drift_Constant calculation is done with time references in uSeconds (EPI is the EPI 
in uSecond units). 


FRS245 The Time_Drift_Constant calculation shall be done using at least 32 bit integer math 
with the result being a 16 bit integer. 


The 1/320000 factor in the Time_Drift_Constant calculation is equivalent to multiplying by the 
worst case clock drift of .0004 and dividing by 128. 


Time_Drift_Constant (in 128 uSec counts) 
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2-4.5.3.3 


= Roundup [(Timeout_Multiplier.PI (C#)+1) * EPI_in_usec * Ping_Interval_EPI_Multiplier / 
320000] 


OR 1 whichever is greater. 
Example: Timeout_Multiplier.PI =2, EPI(in uSec)=8000, Ping_Interval_EPI_Multiplier=100 
Time_Drift_Constant = 8, Time_Coord_Msg_Min_Multiplier = 2 


Connection_Correction_Constant = 7 


Time_Coord_Response_EPI_Limit [per consumer] 


[he Time_Coord_Response_EPI_Limit is used to ensure that a Time Coordination message 
that returns to the producer requesting it, arrives within a time sufficient to prevent the 
possibility of a 16 bit time stamp math rollover. There are other checks to insure that the 
Time_Coordination message returns within the Ping Interval and that not too many Time 
Coordination messages are dropped. 


Time_Coord_Response_EPI_Limit (a value in EPI increments) is used to determine if the time 
between the incrementing of the Ping Count and the Time Coordination response is less than a 
time value that is equal to: 


5 + [Time_Coord_Msg_Min_Multiplier*.000128] + [EPI*(Consumer_Num — 1)]} in seconds. 


To keep the reaction time less than 5.8 seconds, the transport time of the safety message plus 
the transport time of the Time Coordination message minus the minimum Time Coordination 
message [Time_Coord_Msg_Min_Multiplier/.000128] must be less than 5.0 seconds if the 
worst case drift of .5 seconds is considered. This procedure keeps the 
Connection_Correction_Constant within range to prevent rollover at the age check. 


The legal range of values for Time_Coord_Response_EPI_Limit is between 5 to 1000. 


FRS320 If the Consumer_Active_Idle[Consumer_Num-1] == Active, Producers shall check 
that Time Coordination Messages are received within the Time_Coord_Response_EPI_Limit 
and fault the connection if they are not. 


[he Time_Coord_Response_EPI_Limit calculation is done with time references in uSeconds 
(EPI is the EPI in uSecond units). 


FRS247 The Time_Coord_Response_EPI_Limit calculation shall be done in 32 bit integer 
math with the result being a 16 bit integer. 


Time_Coord_Response_EPI_Limit [C#] = 


Roundup( {5000000 + [Time_Coord_Msg_Min_Multiplier[C#]* 128] + [EPI*(C#- 1)]} 
/EPI) 


OR _ 1000 whichever is lower. 


where C# = Consumer_Number 


— 2-96 — 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 2: Safety Protocol Requirements 


Example: if Time_Coord_Msg_Min_Multiplier = 2 (256 us), EPI = 8000 usec, and 
Consumer_Number = 1. 


Time_Coord_Response_EPI_Limit = 626 


2-4.5.4 Producer Dynamic Variables 


The following dynamic variables are producer variables that are common to all multi-cast 
consumers consuming the produced data. 


2-4.5.4.1 Producer_Clk_Count 


FRS248 Each product that produces or consumes safety data shall derive a periodic timer that 
increments a counter (Producer_Clk_Count or Consumer_Clk_Count) every 128 uSecs. 
Producer_Clk_Count must have tolerances and stability within +/- 0.02% or 200 PPM. 


FRS249 Producer_Clk_Count (and Consumer_Clk_Count) shall be 16 bits in length. 


2-4.5.4.2 Producer_Safe_Data_TS 


FRS250 Producer_Safe_Data_TS is a variable that shall be set equal to Producer_Clk_Count at 
the point in time that the Safety_Data for a particular EPI data production is sampled and 
captured from the producing application. 

This location that is sampled is the point where the producing applications time monitoring 
responsibilities end and the safety protocols time monitoring responsibilities begin. This value 
is used as the time stamp for the data that is relative to the producer’s clock. The legal range of 
values is form 0 through 65535. 


2-4.5.4.3 Data_Time_Stamp 


Data_Time_Stamp is the time that the safety data was sampled relative to the consumer’s 
clock. 


The Data_Time_Stamp value is derived by the producer for a single-cast production. 

The Data_Time_Stamp value is derived by the consumer in multi-cast connections. 

The legal range of values is from 0 through 65535. 

For single-cast: 
Data_Time_Stamp = Producer_Safe_Data_TS + Consumer_Time_Correction_Value 
For multi-cast: 


Data_Time_Stamp = Producer_Safe_Data_TS 
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2-4.5.4.4 


2-4.5.4.5 


2-4.5.4.6 


Ping_Interval_EPI_Count 


Ping_Interval_EPI_Count is a count of the number of EPI time periods between the 
incrementing of the Ping_Count. 


Ping_Interval_EPI_Count is used to control Ping Intervals and to control the sending of Time 
Correction messages for multicast producers. 


The Ping_Interval_EPI_Count is incremented at every data production. When 
Ping_Interval_EPI_Count reaches the Ping_Interval_EPI_Multiplier , it is reset to 0, and the 
Ping count is incremented. 


FRS257 For multi-cast producers, Time Correction messages shall be sent to the n consumers 
(where n = | thru Max_Consumer_Number), on the 9" thru n+9 productions of the Ping 
Interval. 


FRS258 The Time Correction message of consumer | shall be sent first, followed by 2, 3,...,n. 


The intent of this logic is to distribute the Time Correction messages at a point within the Ping 
Interval, when the Time Coordination messages should have already arrived and been 
processed for this Ping Interval. 


The legal range of values is from 0 through Ping_Interval_EPI_Multiplier. 


At connection establishment, the Ping_Interval_EPI_Count variable should be set to 0x0000. 


RR_Con_Num_Index_Pntr 


RR_Con_Num_Index_Pntr is a variable used by the multi-cast producer to control the checking 
of the timeout on the reception of Time Coordination messages, and to control the sending of 
Time Correction messages. 


A value greater than or equal to Max_Consumer_Number, indicates that the Time Coordination 
timeouts are not being checked on this EPI, and no Time Corrections are being sent based on 
this EPI. 


A value of 0 thru (Max_Consumer_Number -1) indicates which Time Coordination timeouts 
will be checked (Consumer_Number = RR_Con_Num_Index_Pntr + 1) on this EP] and which 
Time Correction message (Consumer_Number = RR_Con_Num_Index_Pntr + 1) may be sent 
based on this EPI production. 


Time_Drift_Since_Last_Time_Coord [per consumer] 


Time_Drift_Since_Last_Time_Coord is a variable that contains the maximum time drift that 
could have occurred between the producer and the consumer since the last time that a Time 
Coordination message was received. This value is equal to the 
Ping_Int_Since_Last_Time_Coord_Msg_Count times Time_Drift_Per_Ping_Interval. The 
Ping_Int_Since_Last_Time_Coord_Msg_Count is the number of Ping Intervals since the last 
Time Coordination message. 
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2-4.5.4.7 


2-4.5.5 


2-4.5.5.1 


FRS260 The Time_Drift_Since_Last_Time_Coord shall be used to indirectly determine if the 
delay of the Time Coordination message received is significantly greater than the delay for the 
Time Coordination message previously being used. 


The Delay of the Time Coordination message has an impact on the 
Consumer_Time_Correction_Value that will be used. Greater delays in the Time Coordination 
message cause the Time_Stamp to be compensated in a negative direction, causing the age of 
the data to be greater. 


Tf the difference between the delays of two consecutive Time_Coordination messages is greater 
than the EPI time, the later Consumer_Time_Correction_Value may cause the Time_Stamp of 
the next EPI production to actually be less then the Time_Stamp of the previous EPI 
production. This would result in a sequence error at the consumer of the Time_Stamp. 


FRS261 Since the maximum time drift is controlled, either the Last Time_Correction_Value 
minus the Time_Drift_Since_Last_Time_Coord value, or the New Time_Correction_Value 
value, shall be sent to the consumer, whichever is better. 


This prevents long delays in the delivery of a Time Correction messages from causing 
sequence errors in the Time Stamp checks. 


FRS262 For multi-cast producers, a Time_Drift_Since_Last_Time_Coord shall exist for each 
multi-cast consumer, 1 through Max_Consumer_Number. 


The legal range of values is from 0 through 3910 = (5 * 782). 


Worst_Case_Consumer_Time_Correction_Value 


This a temporary value used to determine the Consumer_Time_Correction_Value. 


Producer Per Consumer Dynamic Variables 


The following dynamic variables are producer variables that exist for each consumer. For 
single-cast connections there will be only one variable for each consumer. For multi-cast there 
will be Max_Consumer_Number of variables, each representing an individual consumer. 


Consumer_Time_Value[per consumer] 


Consumer_Time_Value is the time value sent to the producer of a time stamp from the 
consumer or in the Time Coordination Message. A Consumer_Time_Value is received for 
each multi-cast consumer, | through Max_Consumer_Number. 


The legal range of values is from 0 through 65535. 


FRS263 At connection establishment, all Consumer_Time_Value variables shall be set to 
0x0000. 


FRS360 When a Time Coordination Message is received; the producer shall check that the 
Time_Coordination_Section.Consumer_Time_Value is not the same as the last received 
Consumer_Time_Value. If it is, the Time Coordination message shall not be processed. 
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2-4,.5.5.2 


2-4.5.5.3 


2-4.5.5.4 


This check will prevent a producer from processing network generated duplicate Time 
Coordination messages. 
Producer_Rcved_Time_Value[per consumer] 


FRS264 Producer_Reved_Time_Value shall be set equal to Producer_Clk_Count at the point 
in time that the Time Coordination Message information is received from the time stamp of the 
consumer. 


FRS265 A Producer_Rcved_Time_vValue shall exist for each multi-cast consumer, | through 
Max_Consumer_Number. 


The legal range of values is from 0 through 65535. 


FRS266 At connection establishment, all Producer_Rcved_Time_Value variables shall be set 
to 0x0000. 
Consumer_Time_Correction_Value[per consumer] 


The Consumer_Time_Correction_Value exists only for multi-cast safety connections. 


The Consumer_Time_Correction_Value is added to the producer’s data time stamp to allow the 
result to indicate the worst-case earliest time that the data could have been sampled relative to 
the consumer’s clock value. 


A Consumer_Time_Correction_Value exists for each multi-cast consumer, | through 
Max_Consumer_Number. 


Consumer_Time_Correction_Value [Consumer_Number] 

= Consumer_Time_Value [Consumer_Number] 

- Producer_Rcved_Time_Value [Consumer_Number] 

- Connection_Correction_Constant [Consumer_Number] 
The legal range of values is from 0 through 65535. 
FRS268 At connection establishment, all Consumer_Time_Correction_Value variables shall be 
set to 0x0000. 

Ping_Int_Since_Last_Time_Coord_Msg_Count[per consumer] 


Ping_Int_Since_Last_Time_Coord_Msg_Count is a run time count of the number of Ping 
Intervals between Time Coordination Messages for a particular consumer. 


FRS269 For single-cast connections, the Ping_Int_Since_Last_Time_Coord_Msg_Count shall 
be incremented at the 8" EPI production of the Ping Interval. 


FRS270 For multi-cast connections, Ping_Int_Since_Last_Time_Coord_Msg_Count shall be 
incremented every (8* n)" EPI production of the Ping Interval, where n equals the consumer 
number - 1. 
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2-4.6 


2-4.6.1 


FRS271 The Ping_Int_Since_Last_Time_Coord_Msg_Count for any particular consumer shall 
be reset upon the reception of a valid Time Coordination Message from that consumer . 


FRS272 If the Ping_Int_Since_Last_Time_Coord_Msg_Count ever exceeds the 
Timeout_Multiplier.PI + 2 for a connection, that consumer shall be set to the faulted state . 


If the producer is multi-cast, Ping_Int_Since_Last_Time_Coord_Msg_Count exists for each 
multi-cast consumer, | through Max_Consumer_Number. 


The legal range of values is from 0 through 5. 


FRS273 At connection establishment, all Ping_Int_Since_Last_Time_Coord_Msg_Count 
variables shall be set to 0x0000 . 


Producer_Fault_Counter 


For the Extended Format, this is a temporary value used to track the number of data integrity 
errors the producer detects on the reception of Time Coordination messages. This value is 
incremented every time a Time Coordination message is detected with a data integrity error. 
This value will be reset to 0 every hour. If this value reaches the Max_Fault_Number for that 
consumer (SafetyOpen Parameter), the connection will be closed. 


Consumer Data Variables 


[his section describes the data variables that will be used by a safety consumer to receive 
safety data. The internal variables are defined in an attempt to define the behavior of the safety 
data consumer upon the reception of safety data. 


Consuming Connection Status 


[he status of the safety data and the safety connections can be derived from the 
S_Con_Flt_C_Out, the S_Run_Idle_Out flags, and the Init_Complete_Out. Table 2-4.2 
summarizes the logic that the consuming application can use to drive the safety data and status. 


Table 2-4.2 Consuming Safety Connection Status 


S_Con_Fit_ | S_Run_Idle | Init_Complete | Connection Description 
Out _Out _Out Status 
Fault x x Faulted The safety connection is faulted. 


Restart will be required. 
Put the data in safety state. 


OK Idle 0 Idle The safety connection has not been 
activated. 


Put the data in safety state. 


OK Idle 1 Idle The safety connection has been 
activated and the producing application 
is in Idle Mode. 

Put the data in safety state. 
OK Active 0 N/A Illegal condition — can not occur 
OK Active 1 Run The safety connection is active and the 
— 2-101 - 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 2: Safety Protocol Requirements 


2-4.6.1.1 


2-4.6.1.2 


2-4.6.1.3 


producing application is in Run Mode. 
Use the data 


FRS274 The Connection Status of consuming safety connections shall be indicated as shown in 
Table 2-4.2 of Volume 5 Chapter 2 
S_Con_Fit_C_Out 


S_Con_Flt_C_Out indicates to the consuming application if it should put the safety data in a 
safety state because the safety validators have detected a safety connection fault. 
S_Con_Flt_C_Out_Temp is used as a temporary location for this variable. 


The S_Con_Flt_C_Out values are OK and Fault. 


FRS275 At connection establishment, all S_Con_Flt_C_Out flags shall be set to OK. 


S_Run_Idle_Out 


FRS276 S_Run_Idle_Out shall be used by a consuming application to determine if it should 
put the safety data in a safety state. 


FRS277 The S_Run_Idle_Out shall indicate Idle when either the producing application is Idle 
or the Safety Validators are not active. S_Run_Idle_Out_Temp is used as a temporary location 
for this variable. 


The S_Run_Idle_Out values are IDLE or RUN. 


FRS278 At connection establishment, all S_Run_Idle_Out flags shall be set to Idle. 


Init_Complete_Out 


The Init_Complete_Out flag indicates whether the time stamp initialization is complete or not. 
FRS279 S_Run_Idle_Out shall be in Idle until Init_Complete_Out is set to a 1. 


FRS280 After the connection is first established, the consuming application shall close base 
format connections if initialization is not completed within 10 seconds. The consuming 
application shall close Extended connections if initialization is not completed within 8.3 
seconds. 


The S_Run_Idle_Out will indicate Idle, regardless of this timeout. If the timeout is 
incorporated, the error must be latched until the safety connection is closed and a re-open 
attempt is made. 


FRS281 For Single-Cast, the flag Init_Complete_Out shall indicate that the first time 
coordination message has been received by the producer and the producer is producing data 
with the time stamp relative to the consumer’s clock. 


FRS282 For Multi-Cast, the flag Init_Complete_Out shall indicate that the first time 
coordination message has been received by the producer for this consumer and the consumer 
has received the 1“ time correction message based on the time coordination information. 
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2-4.6.2.1 


2-4.6.2.2 


2-4.6.2.3 


FRS283 For Single-Cast, the Data_Time_Stamp value shall be set to 0 by the producer until the 
first time coordination section is received. 


FRS284 If the consumer receives the Data_Time_Stamp as a value other than 0, the time stamp 
checking shall be enabled. 


FRS285 For Multi-Cast, the Data_Time_Stamp value shall always be set equal to the producers 
clock. 


FRS286 The Multi-cast consumer shall enable time stamp checking upon the reception of the 
first time correction section. 


FRS287 For all consumed safety connections, time stamp checking shall be enabled if the 
mode of the data indicates Run. 


Init_Complete_Out_Temp is used as a temporary location for this variable. 


Consumer Input Static Variables 


Connection_Type 


Connection_Type specifies whether the connection is single-cast or multi-cast. For any 
producer, the producer and all consumers must have the same Connection_Type. 


Consumer _Num 


Consumer _Num is the number a Multi-cast Consumer is assigned (1 through 15). 


Network_Time_Expectation_Multiplier 


Network_Time_Expectation_Multiplier is the maximum number of 128 uSec increments that a 
consumer should allow the age of the safety data to reach. 


FRS288 If consumed safety data becomes older then Network_Time_Expectation_Multiplier, 
the safety data shall be put in the safety state . 


The legal range of values is from 0 through 45313, which equates to 0 through 5.8 Seconds. 
The 5.8 second limit, the requirement to check the Network_Time_Expectation at least once 
every 2 seconds, and the maximum Time_Correction value change (or maximum clock drift) 
for a Ping interval is .5 Seconds, will ensure that the clock base value of 8.388 seconds 
(OxFFFF * .000128) does not wrap around between checks. 


The actual network reaction time may be this value in time plus | EPI if the producing 
application is asynchronous to the data production, since in this case the data may be one EPI 
old at the time that the time stamp was placed on the produced data. See section 2-7 for a 
complete explanation of the network safety time. 
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2-4.6.2.4 


2-4.6.2.5 


2-4.6.3 


2-4.6.4 


2-4.6.4.1 


2-4.6.4.2 


Timeout_Multiplier 


Timeout_Multiplier is the number of data production retries to use for in network fault 
detection equations. This is the same value used by the producer. See section 2-4.5.2.2 fora 
further description 


Ping_Interval_EPI_Multiplier 


Ping_Interval_EPI_Multiplier is the number that defines the Ping_Count_Interval for a 
particular connection. The Ping_Count_Interval is equal to the EPI times the 
Ping_Interval_EPI_Multiplier. 


This is the same value used by the producer. See section 2-4.5.2.4 for a further description 


Consumer Connection Derived Static Variables 
These static variables are derived from the input static variables. These static variables are 
derived at configuration time and are used during producer processing. 
Consumer Dynamic Variables 
The following dynamic variables are consumer variables that are used to describe safety data 
reception. 

Consumer_Clk_Count 


Each product that consumes safety data will derive a periodic timer that increments a counter 
(Consumer_Clk_Count) every 128 uSecs (see FRS 248). 


Consumer_Clk_Count will have tolerances and stability within +/- 0.02% or 200 PPM because 
safety devices are required to have clocks with this tolerance. 


Consumer_Clk_Count shall be 16 bits in length (see FRS249). 


FRS340 If the difference between the Consumer_Clk_Count at the time that the data is given to 
the consuming application for use and the Data_Time_Stamp sent with the data exceeds the 
Network_Time_Expectation_Multiplier, the S_Con_Flt_C_Out flag shall be set to “Faulted” to 
indicate that the Reaction Time for the network has not been met. 


Last_Ping_Count 


FRS291 A consumer of safety data shall be able to detect when the Ping_Count has changed. 
This 2 bit variable is used to hold the Ping_Count for comparison on the next reception. 


FRS292 Since the initial production of safety data should have a Ping_Count of 00, the 
Last_Ping_Count shall be initialized to 11. 
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2-4.6.4.4 


2-4.6.4.5 


2-4.6.4.6 


2-4.6.4.7 


Time_Coordination_Count_Down 


FRS294 The Time_Coordination_Count_Down shall be set equal to the Consumer_Number 
upon the reception of a multi-cast ping request. 


FRS295 The consumer shall decrement the Time_Coordination_Count_Down value on 
subsequent reception of consumed data until the value is equal to 0 . 


FRS296 If the value is equal to 1 during any reception of consumed data, the ping response for 
that consumer shall be sent . 


The intent of this logic is to distribute the multi-cast ping responses. 
FRS297 When a connection is first established, the Time_Coordination_Count_Down shall be 
initialized to 0. 
Corrected_Data_Time_Stamp 
This value is the consumer copy of the received Data_Time_Stamp. 


FRS298 For multi-cast, the Corrected_Data_Time_Stamp shall be a sum of the received time 
stamp and the Last_Rcved_Time_Correction_Value . 


Last_Data_Time_Stamp 
This value is the saved copy of the received Data_Time_Stamp. 
FRS299 The Last_Data_Time_Stamp shall be used to detect out of sequence messages . 
FRS300 When a connection is first established, the Last_Data_Time_Stamp shall be initialized 
to 0. 

Last_Rceved_Multi_Cast_Active_Idle 


This value is the saved copy of the received Multi_Cast_Active_Idle. 


FRS301 The Last_Rcved_Multi_Cast_Active_Idle shall be used to detect a change from active 
to idle, which would be considered a fault. 


FRS302 When a connection is first established, the Last_Rceved_Multi_Cast_Active_Idle shall 
be initialized to 0. 


Last_Rcved_Time_Correction_Value 


This value is the saved copy of the received Time_Correction_Value. 


FRS303 The Last_Rcved_Time_Correction_Value shall be used to correct the Time Stamp for 
each multi-cast consumer. 


FRS304 When a connection is first established, the Last_Rcved_Time_Correction_Value shall 
be initialized to 0. 
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2-4.6.4.9 


2-4.6.4.10 


2-4.6.4.11 


2-4.6.4.12 


Time_Correction_Ping_Interval_Count 


This value indicates the number of Ping Intervals that have occurred since the last reception of 
a Time Correction message. 


FRS305 If the Time_Correction_Ping_Interval_Count is greater than the 
Timeout_Multiplier.PI + 1, the connection shall be faulted. 
Time_Correction_Received_Flag 


This flag indicates that a Time_Correction message has been received for this multicast 
consumer and the time stamp can be corrected and checked. 


FRS306 When the Time_Correction_Received_Flag is set, the consumer shall begin the 
process of correcting and checking the time stamp. 
Data_Age 


This value indicates the worst case age of the data in 128 uSec increment. 


Data Age is determined at the point a Consuming Application samples the data. In 
Application-Triggered consumers, this sampling is asynchronous to the data reception, In 
Link-Triggered consumers, this sampling is done when the data is received. 


Data age is defined as the difference between the Consumer_Clk_Count at the sample point 
and the Data Time Stamp when the data was last captured. 


Max_Data_Age 


This value indicates maximum value of Data_Age since the last time that it was reset. 


Consumer_Fault_Counter 


For the ExtendedFormat, this a temporary value used to track the number of data integrity 
errors the consumer detects on the reception of Data and Time Correction messages. This 
value is incremented every time a Data and Time Correction message is detected with a data 
integrity error. This value will be reset to 0 every hour. If this value reaches the 
Max_Fault_Number (SafetyOpen Parameter), the connection will be closed. 
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Safety System Introduction 


This document covers the systems aspect of a Safety Control System that uses a CIP Safety 
Network for its communications functions. It also defines objects and behaviors that support a 
safety configuration model (called the SNCT interface) that meets the 61508 requirements with 
uncertified software and a predominantly non-redundant implementation in the devices. This 
locument will describe those aspects of devices that are necessary to achieve common 
operations and common behaviors that will make the systems appear seamless to customers 
using the Safety Network Configuration Tools. 


The safety system functionality is organized to easily facilitate moving these requirements into 
the appropriate CIP protocol documents. Each major section represents one of the major 
documents; CIP Common, DeviceNet Specification, and the EtherNet/IP Specification. 
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Safety Connection Establishment 


Establishing safety connections is a key system function. There are two safety elements that 
need to be addressed; setting up a connection relationship in an originator, and setting up a run- 
time connection. This section will describe the system requirements to perform both of these 
operations with integrity. . 


Configuring Safety Connections 


This chapter defines the parameters needed to perform the safety protocol. It also defines the 
Safety Segment parameters needed to be passed in the Safety Open to properly set up a safety 
connection. This section will describe how these parameters get assigned and suggest 
reasonable defaults for a safety system. 


The parameters that need to be configured for a safety connection are: 


e Target UNID 

e Originator UNID 

e EPI 

e Ping Interval EPI Multiplier 

e Time Coord Msg Min Multiplier 

e Timeout_Multiplier 

Max Consumer Number 

Network Time Expectation Multiplier 
ASYNC 

Max_Fault_Number (Extended Format only) 


All but the ASYNC parameter are included in the Safety Open service. 


SRS1 The configuration Software for a Safety Connection Originator shall provide a means for 
the following parameters to either be configured or given default values: Expected Packet 
Interval, Target UNID, Originator UNID, Timeout_Multiplier, Ping Interval EPI Multiplier, 
Time Coord Msg Min Multiplier, Max Consumer Number, Network Time Expectation 
Multiplier, ASYNC, Max_Fault_Number (Extended Format only). Table 2-6.1 summarizes 
how these parameters and others will be obtained. 
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Table 2-6.1 Safety Connection Parameters 


Parameter 


Suggested Configuration 
Method 


Suggested Default Value 


Data Expected Packet Interval (EPI) 


User assigned or tool-based 
estimation 


None, user must provide one 


Time Coordination EPI 


Data EPI * Ping Interval 
EPI Multiplier 


Software Calculated 


Time Correction EPI 


Data EPI * Ping Interval 
EPI Multiplier 


Software Calculated 


Target UNID User assigned or obtained None, user must provide one 
by software 
Originator UNID User assigned None, user must provide one 


Timeout_Multiplier 


User assigned 


2 


Ping Interval EPI Multiplier 


Default value for inputs or 
outputs 


100 for inputs 
19 for outputs 


Time Coord Msg Min Multiplier 


Default value on path 


2 for non-bridged 


3 for bridged 
Max Consumer Number Fixed value 15 
Network Time Expectation Multiplier Calculation Calculated 
ASYNC EDS File Input 1 (asynchronous) 


Initial Time Stamp (Extended Format only) 


Dynamic assignment 


None, producer must assign a 
value based on connection 
format and type 


Initial Rollover Count (Extended Format only) 


Dynamic assignment 


None, producer must assign a 
value based on connection 
format and type 


Max_Fault_Number (Extended Format only) 


Default value 


5 


Network Time Expectation Multiplier 


One of the primary calculations required of a Safety Configuration Tool or Connection 
Originator is the calculation of the Network Time Expectation Multiplier. This section 
provides a simplified way to do this calculation. 


Section 2-7.2 defines the Network Time Expectation Multiplier as: 


Network_Time_Expectation_Multiplier > 


(in 128uS increments) 


[EPI_in_sec * Timeout_Multiplier 


+ Safety_Message_Time(max) 


+ Time_Coord_Message_Time(max)]/128uSec 


+ Connection_Correction_Constant 


Some simplifying assumptions can be made as follows: 


e Safety Message Time (max) = | EPI 


e Time Coordination Msg Time = Safety Message Time (max) 
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e Effect of Time_Drift_Constant is negligible (Connection Correction Constant can be 
ignored), 


Under these assumptions, the generalized equation can be stated: 
Network Time Expectation Multiplier = 

[EPI_in_sec * (Timeout_Multiplier +2)] / 128uSec 
as long as the value does not exceed 5.8 seconds. 


The Network Time Expectation Multiplier parameter can now be determined by a common set 
of user inputs and one EDS file parameter. 


Figure 2-6.1 shows where the various parameters shown in Table 2-6.1 are obtained. It also 
shows how these parameters are used by the software to construct the safety segment of a 
Safety Open. 


Figure 2-6.1 Sources for Safety Related Connection Parameters 
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Figure 2-6.2 shows how the Safety Open parameters are mapped in Originators and Targets of 
a safety connection. 
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Figure 2-6.2 Parameter Mapping Between Originator and Target 
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2-6.2 


Establishing Connections 


Section 2-1.9.1.3 defines two types of Safety Open messages. When configuration data is 
transmitted within the SafetyOpen this is defined as a Type 1 SafetyOpen. When no 
configuration data is transmitted within the SafetyOpen this is defined as a Type 2 SafetyOpen. 
This is shown in Figure 2-6.3. 


SRS172 If a connection has configuration data, this configuration data shall only be sent when 

it is needed. Unless the configuration has been changed, this shall be accomplished by sending 
a Type 2 SafetyOpen, and only followed with a Type 1 SafetyOpen if the target responds with 

Device Not Configured error. 


SRS171 When a device receives a Type 1 SafetyOpen containing configuration data and an 
SCID that matches its existing configuration, it shall re-apply the configuration. All existing 
rules checks (i.e. OUNID and TUNID checks) shall still apply. 


Since all safety nodes are required to have NV storage for configuration data, this is only likely 
on device replacement, initial start-up or when the configuration has changed. This process is 
illustrated in Figure 2-6.4. 


SRS173 Targets shall respond to a Type 2 SafetyOpen with an error code 0x01, additional code 
0x0110 (device not configured), when the device is not configured. 


SRS174 When an originator detects that the configuration data held for a device has changed, it 
shall always issue a type | connection request the first time it connects. The SCID returned 
shall be validated against the value held. 

There are two kinds of Type 2 Safety Opens: with and without the SCID 

SRS2 Type 2a: When a target receives a Type 2 SafetyOpen (no configuration data) 
accompanied by a non-zero Safety Configuration ID (SCID = SCCRC+SCTS), it shall compare 


it against the SCID of the configuration and only accept the connection if they match. 


Type 2b: When a target receives a Type 2 SafetyOpen (no configuration data) accompanied by 
a zero value SCID, it skips the check (refer to FRS163). 


Table 2-6.2 SafetyOpen Summary 


Type 1 Type 2a Type 2b 
SafetyOpen With SafetyOpen with SafetyOpen without SCID 
Data SCID check check (FRS163) 

TUNID x x x 

OUNID x x x 

UPID! x x x 

CPCRC x x x 

SCID x x =0 

Config. Data in | Yes No No 

Safety Open 


'UPID is derived from components in the Safety Open or from application data returned in the 
SafetyOpen response. Refer to Section 2-6.7 
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The processing of SafetyOpens in Targets will differ depending on the type of SafetyOpen 
message that is received. Figure 2-6.4 shows the message and event sequence for the Type 1 
Safety Open and the objects that are responsible for the various processing steps. Figure 2-6.3 
shows that the primary difference between processing Type 1 and Type 2 is the step where 
configuration data is passed to a configuration assembly and an owner assigned to that 
configuration. 


Figure 2-6.3 DeviceNet Connection Establishment in Targets for Type 2a Safety Open 
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Figure 2-6.4 General Sequence to Detect Configuration is required 


Unconfigured Target Device 


" 
Connection Originator Validator Object Safety Supervisor | Configuration Assembly 
7 i 7 i 
I ' 1 1 
i 1 1 : 

' ' 1 1 
=i ats a i 

Type 2 Safety Open() State Check() ' 
Mg Device Not__ [> Check State() 
Device Not Configured) Configured() 
legten a ee ie SA 
Type 1 Safety Open() a 
1 
Apply Cohfiguration() 
H 
Sudcess() 
ae eee RCT | 
' 
Safety Open Response() Goto Execute State() 
fo et eee eee nt ee td PS ae et J 
[> Execute State() 
Ti 1 I 1 
I 1 ' ' 
1 1 1 H 
—2-114— 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 2: Safety Protocol Requirements 


2-6.3 


2-6.4 


Recommendations for Consumer Number Allocation 


When a Multi-cast connection is established, the producer of that connection must allocate a 
unique consumer number to the consumer. The main difficulty with this process is not in the 
initial allocation, but in dealing with the case where a producer has closed a connection for 
some reason and now needs to decide when it is acceptable to re-assign that consumer number 
again. 


Since multi-cast producers will continue to produce data even though a connection to a 
particular consumer was closed (i.e. assumes other consumer connections still open), the only 
mechanism available for a multi-cast consumer to detect the loss of the connection is by 
detecting that it has not gotten a Time Correction message within Timeout_Multiplier.PI+1 
ping intervals. During this period, the Consumer still thinks the connection is open, is still 
processing received data, and is still sending Time Coordination responses (even though the 
producer ignores them). 


If a producer were to get a new connection request from another consumer and re-allocate this 
consumer number, there would be two consumers using the same number during this period. 
The producer would again start processing Time Coordination responses and sending Time 
Correction messages with that consumer number. In other words, if the timing were just right, 
the old consumer might never detect the connection has failed and there would exist two 
consumers with the same number sending conflicting clock information and using conflicting 
correction values. While this case will ultimately be detected by the producer through PID 
seeding, a means shall be employed to minimize the occurrence. 


Multi-cast producers shall quarantine consumer numbers that have been taken off-line for 
Timeout_Multiplier.PI+2 ping intervals before it can be re-allocated to another connection. 
The only exception to this is when a Consumer issues a Forward_close to notify the producer 
that the connection is being closed. In this case, the consumer number can be re-used 
immediately. 


Recommendations for Connection Establishment 


When a multi-cast consumer decides to unilaterally close a connection, the only way for a 
producer to detect this event (other than getting a Forward Close from the consumer) is when it 
no longer receives a Time Coordination response for Timeout_Multiplier.PI+2 Ping Intervals. 
During that time interval, the consumer number is still allocated to that consumer. There is a 
strong likelihood that while this connection is still open, that consumer will issue a new 
SafetyOpen. Producers have two options in this case: 


e Search through the existing connections and see if a connection to this same consumer is 
already established and if so, re-issue the consumer number again. 

e Allocate a new consumer and allow the old consumer number to time-out and go through 
quarantine. 


The first option is the more complicated to code, but is the recommended option since it offers 
a more robust re-allocation scheme for consumer numbers. The advantage of the second option 
is that it is simpler to implement, but allows for consumer numbers to languish in quarantine 
longer than necessary. The second option can also make connection startup problematic for 
applications where the number of consumers is > 8. 
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2-6.5 


2-6.6 


If option one is used, the recommended scheme to match up connections should be to match 
up: 

¢ OUNID and 

e Application data path 


If these match up with the parameters of an existing connection, then that device’s consumer 
number can be re-issued. 


Ownership Establishment 


Section 2-1.9 discussed two methods of establishing connection ownership, through the 
software tools or from the SafetyOpen. It indicated that devices are required to support a 
facility to allow “tool only” configuration or originator configuration. It also implied that 
attempts to reconfigure a device via the SafetyOpen will be rejected if the configuration is 
locked. If the “tool only” state is not set, the OUNID of the selected originator can also be set 
by the software tool during target device commissioning for added security. 


This section will define how this capability has been defined in the new Safety Objects. The 
new Safety Objects are required in devices that will be configured by the Safety Network 
Configuration Tool (SNCT). 


To establish ownership of the configuration (and the connection in outputs), the OUNID of the 
originating device is passed to the target in the SafetyOpen message. 


SRS4 Safety Devices shall NV-store the OUNID for the configuration in the device. SRS5 
Also, Safety Devices shall NV-store the signature for the configuration (SCID) in the device. 
The SCID is derived by concatenating the SCCRC and the SCTS in the SafetyOpen. 


SRS6 Output devices shall NV-store the OUNID associated with the safety output connection. 


When the user has tested and verified the tool-generated configuration, they can lock the 
configuration from changes and flag it as “Locked”. The “Configuration Lock” flag is an 
attribute of the Safety Supervisor. To modify it, a password can be provided which provides 
user defined security. 


As a side note, devices which are configured by the SafetyOpen cannot have a “Configuration 
Lock” condition. The assumption is the Lock condition is set and controlled at the connection 
originator. 


Ownership Use Cases 


This section will present a series of connection scenarios where configuration is also being 
attempted. Each scenario will provide a brief description of how the device should deal with 
each case. Most of these cases utilize the Safety Open to configure the device. As such, the 
tool-based configuration features such as the “Configuration Lock” attribute must not be in use. 
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1. The user-designated owner connects and configures an un-owned, un-configured 
input device - (OUNID assigned at first connection) 


The Configuration Lock attribute in the target must be “unlocked” and the Safety Supervisor 
must be in Configure mode; device has no configuration. The SafetyOpen is validated by the 
target device as being correct and the originator OUNID is stored in the target and related to the 
configuration. A single-cast or multi-cast connection is established. Normal operation starts. 


SRS7 The originator of a Type 1 SafetyOpen that configures a previously unconfigured & 
unowned input device shall become the owner of the configuration. 


2. The user-designated owner connects and configures an un-owned, un-configured 
output device — (OUNID assigned at first connection) 


The Configuration Locked attribute in the target must be “unlocked” and the Safety Supervisor 
must be in Configure mode; device has no configuration. The SafetyOpen is validated by the 
target device as being correct and the OUNID is stored in the target and related to the 
configuration and the connection. A single-cast connection is established. Normal operation 
starts. 


SRS8 A Type 1 SafetyOpen that configures a previously unconfigured & unowned output 
device shall become the owner of both the connection and the configuration . 


3. Owner connects and configures an owned, un-configured input device - (OUNID 
assigned by tool) 


The Configuration Lock attribute in the target must be “unlocked” and the Safety Supervisor 
must be in Configure mode; device has no configuration. The SafetyOpen is validated by the 
target device as being correct and the SafetyOpen OUNID matches the stored OUNID. A 
single-cast or multi-cast connection is established. Normal operation starts. 


4. Owner connects and configures an owned, unconfigured output device - (OUNID 
assigned by tool) 


The Configuration Lock attribute in the target must be “unlocked” and the Safety Supervisor 
must be in Configure mode; device has no configuration. The SafetyOpen is validated by the 
target device as being correct and the SafetyOpen OUNID matches the stored OUNID for the 
configuration and the connection. The target stores the configuration. A single-cast 
connection is established. Normal operation starts. 


A second device attempts to connect to an owned single-cast output connection 


If no connections are open the SafetyOpen will be evaluated by the target device. SRS9 Ifa 

Type 1 SafetyOpen is sent where the originator OUNID is different than the OUNID that is 

stored with the connection the SafetyOpen shall be rejected and an error message, “O_UNID 

Mismatch” is returned 

5. Owner connects and attempts to re-configure a tool-owned, configured device — 
(Configuration Lock set) 


SRS 10 If an originator attempts to configure a device with the Configuration Lock attribute set, 
the device shall reject the SafetyOpen and return an error message “Configuration Not 
Allowed” is returned 
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6. Device reconfiguration — Input Device 


The owner of a device sends a SafetyOpen with configuration data plus an SCID (SCCRC & 

SCTS) to the target device. The data may or may not be the same as what exists in the device 
and the SCID may or may not match the existing SCID. Regardless, as long as the following 
process is followed, it should treat the message as a re-configuration. 


SRS11 A target input device that has an existing configuration shall (at a minimum) do the 
following when a type 1 Safety Open is received: 


e Verify that the TUNID in the SafetyOpen matches the device TUNID 

e If configuration data in included (type 1), verify that the OUNID in the SafetyOpen matches 
the stored OUNID 

e Verify the Electronic Key (See THE CIP NETWORKS LIBRARY, Volume 1, Common 
Industrial Protocol (CIP)) matches the device 

¢ Calculate the SCCRC over the received data and confirm that it obtains the same value 

e verify the CPCRC over the configuration is correct, 

¢ start its reconfiguration process (enters Config State), close and inhibit connections during 
the reconfiguration (respond to connection requests with an error response, “Invalid 
Mode/State”’), 

¢ update the configuration and SCID in NV Memory, 

e verify and validate the connection parameters, 

e Validate the application path 

¢ Confirm the safety connection requested is supported 

e Safety parameters are within valid ranges 

¢ transition the connection to the established state, and the device to the executing state. 

e New connections can now be accepted 


A connection of the requested type is established. While new connections can again be 
accepted, these other devices must now either have the new SCID, or connect with an SCID = 
0. 


7. Device reconfiguration — Output Device 


The owner of a device sends a SafetyOpen with configuration plus an SCID to the target 
device. The data may or may not be the same as what exists in the device and the SCID may or 
may not match the existing SCID. Regardless, as long as the following process is followed, it 
should treat the message as a re-configuration 


SRS12 A target output device that has an existing configuration shall (at a minimum) do the 
following when a type | Safety Open is received. 


e Ifthe connection path is to an output resource, verifies that the OUNID in the SafetyOpen 
matches the OUNID for the connection, 

e Verify that the TUNID in the SafetyOpen matches the device TUNID 

e Verify the Electronic Key (See THE CIP NETWORKS LIBRARY, Volume 1, Common 
Industrial Protocol (CIP)) matches the device 

e If configuration data in included (type 1), verify that the OUNID in the SafetyOpen matches 
the stored OUNID for the configuration 

¢ Calculate the SCCRC over the received data and confirm that it obtains the same value 

e verify the CPCRC over the configuration is correct, 
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¢ start its reconfiguration process by closing and inhibiting connections during the 
reconfiguration (respond to connection requests with an error response, “Invalid 
Mode/State”’), 

¢ update the configuration and SCID in NV memory, 

e verify and validate the connection parameters, 

e Validate the application path 

¢ Confirm the safety connection requested is supported 

e Safety parameters are within valid ranges 

¢ transition the connection to the established state, and the device to the executing state. 


A connection of the requested type should now be established. 
8. Connection establishment to a previously owned device (Changing OUNID) 


When attempting to configure a device that has another owner, a SafetyOpen configuration 
request (i.e., Type 1) without a matching OUNID will be rejected with an error response, 
“OUNID Mismatch”. 


SRS129 To clear an existing OUNID, safety targets shall support a “reset to out-of-box” using 
a reset switch on the device or using the special reset command defined in the Safety 
Supervisor. 


SRS15 If the device has a Safety I/O connection when a reset command is received, the reset 
command shall be rejected and an error message returned, “Invalid Mode/State”. In order for 
a device to be reset by command it must not have Safety I/O connections established. 


A second device attempts to connect to an owned multi-cast connection 


A second originator sends a SafetyOpen (i.e., Type 2a, or Type 2b) to a device that has a multi- 
cast connection owned by another originator. If the SCID in the Safety Open is non-zero, the 
SCID is compared to the saved SCID. If the signatures match, the connection is established. If 
the signature does not match, the error response “SCID Mismatch” is returned. The owner 
does not need to be active during this process. 


SRS180 A target device that has an existing configuration shall (at a minimum) do the 

following when a type 2a or 2b Safety Open is received. 

e Ifthe connection path is to an output resource, verifies that the OUNID in the SafetyOpen 
matches the OUNID for the connection, 

e Ifthe SCID is non-zero, confirm the SCID matches the device SCID 

e Verify that the TUNID in the SafetyOpen matches the device TUNID 

e Verify the Electronic Key (See THE CIP NETWORKS LIBRARY, Volume 1, Common 
Industrial Protocol (CIP)) matches the device 

e verify the CPCRC over the configuration is correct, 

verify and validate the connection parameters, 

Validate the application path 

Confirm the safety connection requested is supported 

Safety parameters are within valid ranges 

transition the connection to the established state 


ecoocee 
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2-6.7 


PID/CID Usage and Establishment 


The PID/CID seeding mechanism has been defined to detect message insertion from an invalid 
source. This insertion can occur from another producer sending Safety Data, another producer 
sending Time Correction messages, or an invalid consumer sending Time Coordination 
messages. All these cases will be covered by the PID/CID scheme in the Safety Protocol. The 
key to this is the exchange of PID/CID information during the connection establishment 
process. The Producer will provide its PID to all its consumers, and all the consumers shall 
provide their respective CID back to the producer. This exchange occurs regardless of who 
originates the connection, or what type of safety connection is being established. 


SRS152 During connection establishment the producing and consuming nodes shall exchange 
their respective PID/CID information (Vendor ID + Device Serial Number + Connection Serial 
Number). The originator sends its ID in the SafetyOpen request, and the target returns its ID 
as part of the SafetyOpen Success response. The two cases are shown in Figure 2-6.5. 


SRS178 The PID shall be used to seed Data production CRCs and Time Correction CRC, and 
the CID shall be used to seed the Time Coordination CRC. 


Figure 2-6.5 PID/CID Exchanges for Two Originator Scenarios 


Orginator/Consumer arget/Prducer 


H i 
1 i 


Safety Forward Open() 


CPCRC, OUNID, TUNID, SCID, CID 


Safety Forward Open Response() 


Success, Respnose Data = PID, Consumer #, ID & RPI if needed 


Safety Forward Open() 


CPCRC, OUNID, TUNID, SCID, PID 


Safety Forward Open Response() 


Success, Respnose Data = CID, ID & RPI if needed 
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2-6.7.1 


Proper PID/CID Usage in Multi-cast & Single-Cast Connections 


The diagram shown in Figure 2-6.6 illustrates how the Producer and Consumer ID parameters 
are to be used to generate the CRC seed values for both base and Extended Format connections. 
This diagram shows the multi-cast case, but it also applies to Single-cast connections as well 
(this is done simply for consistency). References to TS _Rollover_Cnt and Rollover Detector 
only applies to the Extended Format is not used in the base formats. The producer seeds are 
generated using only the $1, S3 and S5 generators (i.e. same seed used for S1 and $2 CRC 
calculations) and the CID seed is generated with the S3 and S5 generator. For more 
information, refer to Section 2-1.7.1. 
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Figure 2-6.6 Seed Generation for Multi-cast Connections 
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PID parameters shall be used to seed the CRCs for Produced Data messages and Time 
Correction messages, and CID parameters shall be used to seed the CRC for the Time 
Coordination responses. 


As shown in the figure, multi-cast producers will need to maintain a consumer array to keep 
track of the seed value for each allocated consumer number. The scheme shall also apply to 
Single-cast connections except that only one consumer seed value needs to be maintained. 


The diagram shown in Figure 2-6.7 illustrates how the seed values, set up during connection 
establishment, get used in the run-time data production. 
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Figure 2-6.7 PID/CID Runtime Handling 
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2-6.8 


2-6.8.1 


2-6.8.2 


Network Supported Services 


The purpose of this section is to promote compatibility between devices developed to exchange 
safety data over the CIP Safety Networks. It defines guidelines on which safety services 
should be supported by the different CIP Safety Device Types. The goal is to have basic 
services that are supported by all devices that intend to support a particular CIP Safety 
Connection Category. 


The goal is to allow the development of input and output devices which range from very simple 
discrete I/O to smart high functionality specialty I/O modules. When an input or output 
module reach a certain level of functional requirements, they may need to be viewed as 
embedding a safety Logic Device within the module. 


CIP Safety Device Type 


To simplify the exchange of information and presentation of Safety Data to the users of 
multiple systems, the devices that participate on the CIP Safety Network are divided into 4 
device types. 


e Input Devices 
¢ Logic Devices 
¢ Output Devices 
e I/O Devices 


Input Devices are devices that translate user signals into safety data and send the safety data to 
Logic Devices. Input Devices do not receive safety data other than the safety connection 
status. If a device with input information needs to receive safety data from the other side of the 
safety connection, it should be considered an I/O Device or a Logic Device, and follow the 
guidelines of the I/O or Logic Safety Device Type. 


Logic Devices are devices that process Safety Input Data and Produce Output Data. Direct 
communication between Input Devices and Output Devices is not supported. A Logic Device, 
no matter how simple, has to be between an Input Device and an Output Device. 


Output Devices are devices that present some signal to the user’s environment based on the 
safety data consumed by the device. Output Devices may have status that is produced back to 
the Logic Device. 


I/O Devices are devices that have both Safety Inputs and Safety Outputs. 


CIP Safety Connection Category 


All Safety Connection can be placed in one of four Categories. They are: 


e Input_Device_To_Logic_Device 

¢ Logic_Device_To_Output_Device 

e Logic_Device_To_I/O_Device 

e (an Output device with Status is considered an I/O Device) 
e Logic_Device_To_Logic_Device 
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2-6.8.3 


2-6.8.4 


Logic Devices may chose to support any or all of the Safety Connection Categories. If a device 
does support a Safety Connection Category, it should support all the Recommended Services of 
that category. 


Safety Connection Services 


The following table lists all the defined Safety Validator Services that Connection Targets or 
Connection Originators can support. 


Table 2-6.3 Originator/Target Service Mapping 


Connection Originator or 
Target Safety Connection Types Validator Type 
Target Single-Cast [Producer [Type 1 
Target ISingle-Cast (Consumer [Type 2 
Target /Multi-Cast [Producer [Type 3 
Originator Single-Cast [Producer [Type 1 
Originator ISingle-Cast {Consumer [Type 2 
Originator Multi-Cast {Consumer IType 4 


The following table lists the Safety Validator Services that Connection Targets or Connection 
Originators should not support. Multi-cast producers are not required to initiate connections to 
its consumers; the consumers must connect to it; Multi-cast Consumers should be the 
connection Originator, and Multi-cast Producers should be connection targets. 


Table 2-6.4 Unsupported Originator/Target Service Types 


Connection Originator or 
Target Safety Connection Types Validator Type 
Target \Multi-Cast consumer IN/A. 
Originator IMulti-Cast Producer IN/A 


Services Supported for each Category 


The following tables list the preferred Safety Connection Services for various Connection 
Categories. For each Safety Connection Category, the different columns represent preferred 
methods of establishing safety connections between the two devices. For any particular device, 
only one column would be supported at one time. 
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Table 2-6.5 Connection Categories and Supported Services 


‘Supported Services for Input or Output Type 


Safety Connection Category 1 2 3 


Input Logic Logic 


Safety C ion S Device Device Device 
Safety Connection Service 
y To To To 


Logic Output 1/0 Device 


Originator 


or Target Safety Connection Type Device | Device | (Output w Status) 


Input & Target Single-Cast Producer 


Output Target Single-Cast Consumer 


Devices | Target Multi-Cast Producer 


Originator Single-Cast Producer 


Logic 
Devices 


Originator Single-Cast Consumer 


Originator Multi-Cast Consumer 
Op1,2,3 = Optional Combinations 
R = Recommended Services for compatibility 


O = Optional Service 
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Figure 2-6.8 Recommended Connection Types 
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Table 2-6.6 Logic-to-Logic Supported Services 


Safety Connection Category 4 
Safety Connection Service Logic Device to Logic Device 


Originator Supported Service Combinations 
or Target Op! Op2 Op3 Op4 


Safety Validator Type 


Logic Target Single-Cast Producer 


Device Target Single-Cast Consumer 


Target Target Multi-Cast Producer 


Logic | Originator] — Single-Cast Producer 


Device | Originator] Single-Cast. | Consumer 


Multi-Cast Consumer 


s= Single Cast, m= Multi-cast, 
R=Recommended Basic Service for compatibility, 


O=Optional Service 
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Figure 2-6.9 Recommended Connection Types for Logic to Logic 
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2-7 System Reaction Time 


2-7.1 Introduction 


The system reaction time is the worst-case time from a safety related event as input to the 
system or as a fault within the system, until the time that the system is in the safety state. 


Figure 2-7.1 System Reaction Time 
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Network Time Expectation 


To determine the system reaction time of any control chain the user shall add up the 
components of the safety chain. 


For example, the system reaction time of the example above would be: 


System reaction time = Sensor reaction time 
+ Input reaction time 
+ Network reaction time 
+ Controller reaction time 
+ Network reaction time 
+ Output reaction time 
+ Actuator reaction time 


2-7.2 Network Time Expectation 


The Network Time Expectation is a portion of the System Reaction Time. The Network Time 
Expectation is the worst case time, from the time the data is captured by the safety data 
producer, until the consuming application recognizes a safety state. This also includes errors 
during production and consumption. 
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2-7.3 


The Network_Time_Expectation_Multiplier used in the previous sections of this document, 
represents the worst case measured time from the time the data is captured by the safety data 
producer until the time that the consuming application recognizes a safety state indication. 


The Network_Time_Expectation_Multiplier value necessary to ensure a timeout error is not 
detected is: 


Network_Time_Expectation_Multiplier > 
(EPI * Timeout_Multiplier 
+ Safety_Message_Time(max) 
+ Time_Coord_Message_Time(max))/128uSec 
+ Connection_Correction_Constant 


Where: 


Safety_Message_Time(max), is the actual time from the data being captured by the safety data 
producer until the time that the safety data is passed to the consuming application for use. 


Time_Coord_Message_Time(max), is the maximum time it could take for the time 
coordination information to be sent from the consumer to the producer. This is measured from 
the time the Consumer_Clk_Count is captured to Consumer_Time_Value until the time 
Producer_Clk_Count is captured to Producer_Reved_Time_Value. 


Timeout_Multiplier is a parameter that is needed by the CIP safety protocol processing (refer 
to FRS230). This value determines the number of messages that may be lost before declaring a 
connection error. A Timeout_Multiplier of 1 indicates that no messages may be lost. A 
Timeout_Multiplier of 2 indicates that | message may be lost, etc. In addition to the 
Timeout_Multiplier checks within the protocol, reaction time checks are also performed. A 
reasonable default for the Timeout_Multiplier would be 2. A reasonable limit would be for 
configuration software to restrict the Timeout_Multiplier to integer values from 1 to 4. For the 
ExtendedFormat the Timeout_Multiplier may be increased to 255 as long as the Network Time 
Expectation value does not exceed 5.8 seconds. 


Connection_Correction_Constant is a value in 128 uSec increments that is subtracted from 
the time stamp to represent the worst case error due to Time drift, the asynchronous nature of 
the producer and consumer clocks, and the minimum time for the Time Coordination Message 
to traverse from the consumer to the producer. 


See the Section 2-6.1 for a discussion of the simplified forms of this equation that can be used 
for configuration purposes. 


Produced Data Network Reaction Time 


For CIP safety networks used on producing devices that have a constant delay or whose safety 
time is synchronized to the data production: 


Network Reaction Time = Network_Time_Expectation_Multiplier * 128 uSec 


For CIP safety networks used on producing devices that have a producing application periodic 
cycle not synchronized to the data production: 


Network Reaction Time = Network_Time_Expectation_Multiplier * 128 uSec + EPI 
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2-7.4 


Equations for Calculating Network Reaction Times 


The most logical place for the user to set and determine the Network reaction times is at the 
logic device since it is very likely both the configuration holder and connection originator. 


There are two cases of safety connection reaction times for most logic devices. They are: 


e Input Connection reaction time 
¢ Output Connection reaction time 


The following table defines the producing application and consuming application for the 
Network reaction time Cases above. 


Table 2-7.1 Connection Reaction Time Type — Producing/Consuming Applications 


Connection Reaction Time Producing Application Consuming Application 
Type 

Safety Input Input Module Controller 

Safety Output Controller Output Module 


Figure 2-7.2 shows the analysis of the Reaction Time components. The time enforcement 
analysis is done from the Output signal back to the Input signal. Doing the analysis from the 
Output signal back to the Input signal allows the effects of asynchronous productions to be 
seen. 


The analysis assumes that the output module will have an internal cycle that checks the age of 
the last received output data. The age of the output data will be maintained at less than the 
Network_Time_Expectation_Multiplier (NTEM) value. 
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Figure 2-7.2 Reaction Time Derivation 
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The oldest input captured on 
cycle (n-1) will be an input 
produced at a time NTEM prior 


The oldest age of an input produced on this 
production will be the maximum time enforced 
by the input module 


From an analysis point of view, a controller to controller connection would be treated the same 
as an Input connection. 


For an Input or Controller to Controller Connection: 
Network reaction time = Network_Time_Expectation_Multiplier * 128pS 


For a Connection to an Output Module: 
Tf the Output Production is Asynchronous to the Controller Cycle: 
Network reaction time = Network_Time_Expectation_Multiplier * 128pS 


Tf the Output Production is Synchronous to the Controller Cycle: 
Network reaction time = Network_Time_Expectation_Multiplier * 128pS - EPI_in_Sec 


The Output Connection cases can be simplified to: 
Network reaction time = Network Time Expectation Multiplier * 128nS + (EPI_in_Sec * (ASYNC 
-1) 


Where the ASYNC parameter is defined as follows: 
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2-8 


ASYNC Parameter 
If the producing application is synchronous with data production, ASYNC=0. If the producing 
application is asynchronous to the data production, ASYNC = 1. This ASYNC parameter shall 


be provided to the Safety Configuration software via an EDS file entry. The default value in 
cases where it is not provided shall be 0. 


Network PFH 


This section will describe the calculations used for the determination of the network PFH. The 
network PFH must meet the 1% rule from the German Safety Bus Paper’. The network is 
targeted at SIL 3 systems therefore the PFH must be <10-9 (or <10-7 if a 1% factor is included 
in the calculations). 


The safety network protocol consists of four parts, safety data, time stamp information, the 
multi-cast time correction information, and the time coordination ping response. Each of these 
parts has its own protection that contributes to the PFH. 


Figure 2-8.1 Network Protocol Reliability Block Diagram (RBD) 


R(P)conn sec R(P)aata R(P)ping response 


From the RBD in Figure 2-8.1, the equation for the overall network residual error rate is: 
Equation 2-8.1 Overall Network Residual Error Rates 

R(PJT = RG) data + R)time stamp + R(P)time coordination R(P) time_comrection 
When applying the residual error rates in the calculation of the PFH, it is important to note that 
the time coordination and the multi-cast time correction information are transmitted at rates 
other than the rate of the time stamp and data. Using the different transmission rates and the 


information from the RBD, the following equation for the overall PFH can be derived: 


Equation 2-8.2 PFH for Single-Cast Connections 


A=3600 * (((R(P)iime stamp + R(P)data )* Vmessages) + (R(P)time coordination * Vping ))* 
(Num_of_Nodes-1) * 100 


The equation for multi-cast PFH is shown below: 


* The one percent factor is used to assure that the network will only use 1% of the PFH budget, based on the 
recommendations of the German Safety Bus Guidelines. See: Draft proposal test and certification guideline, safety 
bus systems, BG FachausschuB Elektrotechnik 28-May-2000, 
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Equation 2-8.3 PFH for Multi-cast Message Connections 


A=3600 *(((R(P)iime stamp + R(P)aata )* Vinessages) + ((R(P)time coordination R(P)kime correction )* 
Vping * NoC/P )) * (Num_of_nodes-1) * 100 


The factors in the above equations are: 


vmessages Transmission rate in messages/second 
vping Transmission rate in messages/second 
NoC/P Number of Consumers per Producer 
3600 conversion of hours to seconds 
100 1% factor 
The following table summarizes the worst-case result. The numbers are obtained from detailed 
calculations and the formulas above. 
Figure 2-8.2 Summary of PFH Calculations 
Inputs 
Expected Packet Interval (EPI) 0.010 Seconds 
Ping Interval 0.524 Seconds 
Number of Nodes (m) 63 
Multi-Cast Consumers: 15 
Bit Error Rate (p) 0.001 
Single 
Results Cast Multi Cast 
R(p)data <= 2 bytes R(p) data section - 2 bytes of data 7.02E-20 7.02E-20 
R(p)data >= 3 bytes R(p) data section - 250 bytes of data 2.85E-24 2.85E-24 
R(p)data R(p) data section | __7.02E-20 7.02E-20 
R(p)ts R(p)time stamp section | 3.18E-18 | 3.18E-18 
R(p)multi R(p) Time correction message 1.40E-18 
R(p)reply R(p) Time coordination message 1.40E-18 1.40E-18 
Msg_per_sec Messages per second = 1 / EPI 100 100 
Rpl_per_sec Replies per second = | / Ping_Interval 1.91 1.91 
A 7.32E-09 9.05E-09 
% of 1.00E-07 goal, up to 100% is OK 7.32% 9.05% 
PFH = A/100 7.32E-11 9.05E-11 
% of SIL 3 (1.00E-07) PFD limit, up to 1% is 
OK 0.0732% 0.0905% 
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2-8.1 Summary of PFH results for Extended 


The following figure summarizes the worst-case result. The numbers are obtained from and the 
‘ormulas above. 
Figure 2-8.3 Summary of PFH Calculations 
Inputs 
Expected Packet Interval (EPI) 0.010 Seconds 
Ping Interval 0.524 Seconds 
Number of Nodes (m) 63 
Multi-Cast Consumers. 15 
Bit Error Rate (p) 0.001 
Single 

Results Cast Multi Cast 
R(p)data <= 2 bytes R(p) data section - 2 bytes of data | 5.05E-22 | 5,05E-22 
R(p)data >= 3 bytes R(p) data section - 250 bytes of data | 4.34E-25 4.34E-25 
R(p)data R(p) data section 5.0SE-22 5.05E-22 
R(p)ts R(p)time stamp section 1.26E-22 1.26E-22 
R(p)multi R(p) Time correction message 1.31E-18 
R(p)reply R(p) Time coordination message 1.13E-18 1.13E-18 

Msg_per_sec Messages per second = 1 / EPI 100 100 
Rpl_per_sec Replies per second = 1 / Ping_Interval 1.00 1.00 
A 2.66E-11 8.18E-10 
% of 1.00E-07 goal, up to 100% is OK 0.0266% 0.8183% 
PFH = A/ 100 2.66E-13 8.18E-12 
% of SIL 3 (1.00E-07) PFD limit, up to 1% is 

OK 0.0003% 0.0082% 


2-8.2 PFH Calculation for DeviceNet Safety Messages 


Using the equations shown in section 2-8 it is possible to calculate the worst-case PFH. From 
the summary table presented in section 0 it can be seen that the 2 byte formats provide the 
worst case PFH for the system. Since this PDF/PFH is < 10” it clearly meets the SIL3 
requirements for IEC 61508. 
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2-8.3 


2-9 


2-9.1 


2-9.1.1 


2-9.1.2 


PFH Calculation for EtherNet/IP and SERCOS III Safety Messages 


Using the equations shown in section 2-8 it is possible to calculate the worst case PFH. From 
the summary table presented in section 0 it can be seen that the 2 byte formats provide the 
worst case PFH for the system. Since this PDF/PFH is < 10” it clearly meets the SIL3 
requirements for IEC 61508. 


DeviceNet Requirements 


Safety Network Implications on DeviceNet 


This section provides the specific requirements to implement DeviceNet Safety. 


CAN Message Encoding 


The safety message is encoded in a standard DeviceNet message. Figure 2-9.1 shows the 
format of the message. 


Figure 2-9.1 Standard CAN Message Encoding Showing Safety Message 


Physical Addressing 


Standard DeviceNet Safety Message Standard DeviceNet 

SOF | Identifier | RTR Control CRC ACK EOF 
1 bit | 11 bits 1 bit 6 bits 16 bits 2 bits 7 bits 
Native CRC Coverage 


The following restrictions are placed on devices implementing DeviceNet Safety: 


e Each DeviceNet Safety device shall always operate using a single MACID (node address). 
e Only the safety configuration tool can set identifiers and parameters. If switches are used 
for these settings changes in the state of the switches are required to be monitored and 
verified against the expected configuration (refer to Chapter 9). The monitoring must be 

done during configuration, startup and run time. 


Use of DeviceNet Identifiers 


SRS95 During connection processing of a SafetyOpen DeviceNet safety identifiers shall be 
assigned from the available pool of DeviceNet Group | identifiers . 


The use of Group 1 identifiers ensures that safety messages have the highest priority during 
arbitration. The 12 lowest numbered DeviceNet identifiers are available for use by safety 
connections. The remaining 4 Group | identifiers are reserved for standard connections (from 
the existing predefined Master-Slave connection set). This partitioning ensures that all of the 
safety messages will be of a higher priority during arbitration. 


Table 2-9.1 shows how the safety connections use identifiers with MSGID in the range of 0 to 
B (hex). 
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Table 2-9.1 Group! identifier space 


Group] identifiers 


bit 10 =0 | bits 9,8,7,6 MSGID | bits 5,4,3,2,1,0 MACID 

Group] ID used for safety 0 0000 Src OR Dest MACID 
Group] ID used for safety 0 0001 Sre OR Dest MACID 
Group! ID used for safety 0 0010 Src OR Dest MACID 
Group] ID used for safety 0 0011 Sre OR Dest MACID 
Group] ID used for safety 0 0100 Sre OR Dest MACID 
Group] ID used for safety 0 0101 Sre OR Dest MACID 
Group! ID used for safety 0 0110 Sre OR Dest MACID 
Group! ID used for safety 0 Ol Sre OR Dest MACID 
Group] ID used for safety 0 1000 Sre OR Dest MACID 
Group] ID used for safety 0 1001 Sre OR Dest MACID 
Group! ID used for safety 0 1010 Sre OR Dest MACID 
Group] ID used for safety 0 1011 Sre OR Dest MACID 
Slave's I/O Multi-Cast poll response message 0 1100 Sre MACID 

Slave's I/O COS or cyclic message 0 1101 Sre MACID 

Slave's I/O Bit strobe response 0 1110 Sre MACID 

Slave's I/O Poll response or COS/cyclic 0 1111 Sre MACID. 
acknowledge message 


In order to preserve connection ID’s, the rules in the following sections shall be implemented 
for the allocation of connection ID’s. 


Typically the connection originator is a client device like a PLC or Safety Monitor, while the 
target is a server device like an I/O module. The client device will typically maintain more 
connections than the server device(s). This new (DeviceNet specific) algorithm will help 
achieve more total network connections than the standard CIP allocation model. 


2-9.1.2.1 Basic DeviceNet Algorithm (General Model) 


SRS96 Safety connection originators shall initially ask the target (via SafetyOpen) to allocate 
one, two, or three identifiers according to the rules stated in Table 24. 

(This is accomplished by inserting 0xFFFFFFFF identifiers in the SafetyOpen request sent to 
the target) 


SRS97 If a safety target cannot or refuses to allocate the identifier(s), the target shall respond to 
the Safety Open request with a 0x01 general error status with extended status 0x031F 
indicating no connection resources are available. 


The originator receives the SafetyOpen response. 


SRS98 If the target has allocated identifiers from its pool, it shall insert them into the 
SafetyOpen success response. 


The originator accepts these and the connection is completed. 
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2-9.1.2.2 


2-9.1.2.3 


2-9.1.2.4 


2-9.1.2.5 


If the target has not allocated identifiers from its pool then the originator has the option to 
allocate identifiers from its own pool. If the originator does allocate the identifier(s) then it 
must convey this data to the target (via a a Safety Open) 


Tf the originator cannot or refuses to allocate an identifier then the connection cannot be 
established. 


Case 1 (Target Allocates Identifiers) 


This first scenario has the originator requesting that the target allocate the connection 
identifiers and the target agrees to do so. 


The connection originator asks the target (via Safety Open) to allocate one, two or three 

identifiers. 

e The target agrees to allocate the identifier(s) and responds to the Safety Open request with 
success. 


e The originator receives the Safety Open response and accepts these identifiers and the 
connection is completed. 


Case 2 (Target Cannot Allocate Identifiers) 


This second scenario has the originator requesting that the target allocate the connection 
identifiers but the target cannot or refuses to do so. 


e The connection originator asks the target (via Safety Open) to allocate one, two or three 
identifiers (identifier = OxFFFFFFFF). 

e The target chooses not to allocate the identifier(s) and responds to the Safety Open request 
with a 0x01 general error code with extended status 0x05 indicating that the resources are 
not available. 

e The originator receives the Safety Open response, sees that target cannot allocate identifiers 
and then chooses to allocate identifiers from its own pool. 

¢ The originator then constructs a 2" Safety Open with the identifiers specified. 

e The target accepts this Safety Open and the connection is completed. 


Case 3 (Originator Allocates Identifiers) 


This third scenario has the originator deciding to allocate its own identifiers with asking the 

target. 

¢ The connection originator allocates the identifiers from its pool and enters these values into 
the Safety Open which is then sent to the target. 

e The target accepts this Safety Open and responds with success. 

e The originator receives the Safety Open response and the connection is completed. 


Order of MSGID Allocation 


As stated before each node has a total of 12 Group] identifiers that can be used for safety 
connections. 
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2-9.1.2.6 


SRS99 In order to provide consistency among producers and consumers, the following rule 
shall be used when allocating identifiers: The first MSGID to be allocated shall start at the 
highest available value and move downward. 


Thus the first MSGID would be B(hex) or 1011 (binary) and the next would be A(hex) or 
1010(binary). 


Rules for Connection ID Assignment 


The following rules for DeviceNet ID assignment shall be followed by Safety targets, 
originators and bridges. These rules provide repeatable ID allocation for a system where one or 
no routers are connected to DeviceNet. It effectively takes unused IDs from target devices and 
provides them to bridges. Because one resource, the router, is allowed to ask for these 
resources, it should work repeatably. But any attempt to extend this to other originators could 
result in a situation where repeatable power up was not achievable. 


Rule 1: All on-link multicast originators provide the 3 group 1 ID when establishing a 
connection. 


Rule 2: All off-link multicast connection originators (routers) request the 3" group 1 ID from 
the target 


Rule 3: The group | ID in targets are divided into 2 types, reserved and free. 


The reserved IDs are equal to 2 x the maximum number of safety connections that a device can 
support. The maximum number of connections is specified when a device is configured. 


The number of free [Ds is equal to Max group 1 ID (12) — reserved IDs. 
In most target devices, this could be a default value and the user would never need to change it. 


Rule 4: Each target would provide 2 reserved group | IDs to multicast or single cast originators 
until its reserved IDs are depleted. Once its reserved IDs are depleted it would reject requests 
to establish new connections. But it would still allow originators to try to establish multicast 
connection to multicast productions that were already established. 


Rule 5: Each target would provide the 3" group! ID to multicast originators from its free pool. 
Once the free pool is exhausted, it would reject the request and the originator would need to 
supply the 3 ID 
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Table 2-9.2 DeviceNet ID Assignment Rules 


ConnectionType Intermediate (First) Last (Only) Hop Last (Only) Hop Last (Only) Hop 
Hop 1“ attempt 2" attempt 3" attempt 
Singlecast T = O: Target Router T = O: Target Connection Fault, Connection Fault, 
O=T: Originator or O=>T: Target Connection cannot be Connection cannot 


Originating Router established. be established. 
Multi-cast T= O | T= O: Target Router T = O: Target T= O: Target Connection Fault, 


(typical; input 
module, output 


O=T: Originator or 
Originating Router 


O = T: Conditional** 


O = T: Originator (if first 


Connection cannot 
be established. 


TC: Target request was Target) 
module status) TC: Target Router TC: Target 
Multi-castO => T | T= O: Target Router T= O: Target T => O: Originator Connection Fault, 


O=T: Originator or 
Originating Router 
TC: Originator or 


O=T: Originator 


TC: Originator or 
Originating Router 


O=T: Originator 


TC: Originator or 
Originating Router 


Connection cannot 
be established 


Originating Router 


TC refers to the Time Correction Connection 
** Originators will default to providing this ID. If the CCO object is used, the originator will 
either provide this ID on the first request or ask the target for the ID based on the "ID 
Allocation" attribute in the CCO object (default is to provide the ID). Bridges will always ask 
the Target for this ID first. 


Table 2-9.2 illustrates the rules for Connection ID Assignment. For non-bridged connections, 
the last 3 columns are of most interest. For example, an originator requesting a single cast 
connection, the target would be asked to supply both the T=>O and the O=>T connection IDs. 


For a typical Multi-cast Input module, the connections are originated by the multi-cast 
consumer (i.e. logic device). In this case, the data is flowing from T=>O. Table 2-9.2 shows 
that the target (i.e. input module) is asked to allocate the IDs for 2 of connections when the 
originator is on-link, but could be asked to supply all 3 if the originator is off-link and routing 
the request through a bridge. This is done by the originator inserting OxFFFF in the ID fields. 


The SafetyOpen success response will support up to 3 IDs to be allocated by the target. Ifa 
target does not have available all the IDs being requested, the target should respond with Error 
Code 0x01, extended code 0x05 (Identifier resources not available). In this multi-cast case, the 
target also needs to recognize when the connection being requested already exists (i.e. multi- 
cast production) and may need to allocate identifiers already assigned. 


Table 2-9.2 illustrates the rules for Connection Id Assignment. For non-bridged connections, 
the last 3 columns are of most interest. For example, an originator requesting a single cast 
connection, the target would be asked to supply both the T=>O and the O=>T connection Ids. 


For a typical Multi-cast Input module, the connections are originated by the multi-cast 
consumer (i.e. logic device). In this case, the data is flowing from T=>O. Table 2-9.2 shows 
that the target (i.e. input module) is asked to allocate the Ids for 2 of connections when the 
originator is on-link, but could be asked to supply all 3 if the originator is off-link and routing 
the request through a bridge. This is done by the originator inserting OxFFFF in the Id fields. 
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2-9.1.2.7 


2-9.1.2.8 


2-9.1.2.9 


2-9.1.2.10 


The SafetyOpen success response will support up to 3 Ids to be allocated by the target. Ifa 
target does not have available all the Ids being requested, the target should respond with Error 
Code 0x01, extended code 0x05 (Identifier resources not available). In this multi-cast case, the 
target also needs to recognize when the connection being requested already exists (i.e. multi- 
cast production) and may need to allocate identifiers already assigned. 


The originator has the option of re-initiating the SafetyOpen and requesting less IDs. As 
illustrated in the table, originators who are multi-cast consumers can only allocate the ID for 
the O=>T identifier. 

Single-Cast Message Connections 


The basic algorithm described above applies to these two connection types. 


Multi-Cast Message Connections 


SRS100 Multi-Cast producers must allocate an identifier from its own pool, i.e. the source 
MACID must be that of the producer. Multi-cast producers shall reject any connection request 
that attempts to assign IDs for its produced data or time correction data The multi-cast 
consumer may follow the basic algorithm described above. 


Why must the producer allocate the producing identifier? 


Assume the consumer allocated the identifier and the multi-cast producer begins producing on 
this identifier. 


Then a second multi-cast consumer is added to the producer list. 
Then the original consumer is shut down and restarted. 


The multi-cast producer will detect the loss of the first connection but must keep producing 
data for the other connection. 


Then when the original consumer is back on-line, the previously allocation identifier is 
unallocated (to the consumer viewpoint). 


If another connection is made to this consumer, then this identifier could be reused and a 
network conflict would occur 


DeviceNet ID Quarantining Requirements 


Target devices need to take care that they don’t re-allocate any group | IDs until they are 
certain that the IDs are no longer being used by the device they had been previously allocated 
to. To assure that this condition will not occur, the following algorithm must be followed: 


SRS179 When a safety device closes a connection in which group | IDs were allocated to 
another device, the group | ID shall be placed into quarantine for a period equal to the 
(connection_EPI * Ping_Interval_Multiplier) * (Timeout_Multiplier.PI+2). During this time, 
the ID cannot be used or allocated to another device. 
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2-9.1.2.11 


2-9.2 


2-9.2.1 


2-9.2.1.1 


Tf an originator who borrowed an ID detects the communication failure and re-issues a new 
connection request before these IDs are removed from quarantine, devices can define schemes 
that detect these requests and pull the IDs from quarantine early and return them to the 
originator. However, care must be taken to assure that this is done with integrity. 


Restrictions on Standard DeviceNet Features 
Because of the potential for safety node disruption, Safety devices should not implement the 


DeviceNet Quick Connect feature. 


Safety System Throughput Over DeviceNet 


DeviceNet Safety Performance 


The performance of producer-consumer I/O connections on DeviceNet Safety depends on: 


e The baud rate of the network, 
e The packet size for the various connections, 
e The type and number of safety connections used. 


Application Example 1 


The sample application shown in Figure 2-9.2 will be used to estimate the network 
performance for an application and maximum EPI that can be supported for a given baud rate, 
and reserved bandwidth percentage. The reserved bandwidth is required to allow for standard 
traffic for connection establishment, diagnostics, and standard Class 3 messaging. 


Figure 2-9.2 Sample Application 


DeviceNet Safety 


For example, a typical safety input might be configured to use a multi-cast or a uni-directional 
point-to-point safety connection to produce safety data to multiple consumers or one consumer 
respectively. Which is used will affect the maximum EPI of the application. A safety network 
software tool, interested in determining the number of safety nodes and reaction time that the 
application can support, can analyze the application information to provide the user with 
reaction times and best case EPI values. 
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Table 2-9.3 Estimated Application Performance 


UniDir | Multicast Bi-Dir Total 
Connections Required 16 0 0 
Baud Rate 500K 
Reserved Bandwidth 40% 
Safety Payload Size (in bytes) 1 1 1 
Bytes per production 7 7 26 
Total Bits per production 125 125 478 
Total Bits for all connections 2000 0 0 2000 
Number of productions per second 150 
Best EPI in msec, rounded up 7 


In this example, the baud rate is assumed to be 500K, bit stuffing is assumed to be a worst-case 
20%, and the reserved bandwidth is set to 40%. After all of the calculations are made, the best 
EPI would be approximately 7 mSec. The EPI value is rounded up to the nearest integer. 


Once these numbers are known, they can be put into a Safety Loop Timing tree to calculate the 
reaction time of the application. Estimated scan times for the Safety Monitor (SM) is set at 2.5 
ms. 


Figure 2-9.3 Example Safety Loop Timing Tree 


Timing Pyramid for Input -> SM Output 
SM Processing 


2.50 ms 
Sample Latency Latency 
2.50 ms 0.00 ms 
Consumer Transfer Producer Out 
2* RPI---> 14 ms 0.00 
Input sample Output Delay 
1 ms 15 ms 
<—— 35.00 > 
Safety Time 


The safety loop time is worst case in that the network transfer times approximate worst-case 
watchdog time limits and that the logic engine is running asynchronous to the network updates. 


In this application example, the standard DeviceNet messaging is neglected in these equations. 
The assumption is that the 40% reserved bandwidth will be sufficient for infrequent Class 3 
DeviceNet. This assumption may not be true in cases where high bandwidth utilization is 
assumed or Master/Slave is also on the same wire. This application also assumes that ping 
responses are much slower than the safety EPI and would sent using the reserved bandwidth. 
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2-9.2.1.2 Application Example 2 


Figure 2-9.4 Application with Interlocked Safety Monitors 


DeviceNet Safety 


A second example application is a combined Safety and Standard DeviceNet application. The 
Safety application is 7 inputs to one Safety Monitor with local outputs. Two bytes of safety 
payload data on single-cast connections are assumed. On standard DeviceNet, the application 
has a single Scanner, 16 Bit-strobe Inputs and 16 Polled outputs. 2 bytes of standard data are 
transferred between each node. Using a reserved bandwidth of 80% (70% for standard, 20% 
Safety and 10% margin), we calculate the following Safety EPI: 


Table 2-9.4 Estimated Application Performance 


UniDir Multi- Bi-Dir Total 


Connections Required 7 0 1) 
Baud Rate 500K 
Reserved Bandwidth 80% 

Safe Payload Size (in bytes) 


2 
Bytes per production 8 7 26 
Total Bits per production 134 125 478 
Total Bits for all connections 938 0 0 938 


Number of productions per 106 
second 


Best EPI in msec, rounded up 10 


The reaction time would be: 


Figure 2-9.5 Timing Pyramid for Interlocked Safety Monitors 


Timing Pyramid for Input -> SM Output 
SM Processing 
2.50 ms 
Sample Latency Latency 
2.50 ms 0.00 ms 
Consumer Transfer Producer Out 
2* EPI ---> 20 ms 0.00 
Input sample Output Delay 
2ms 15 ms 
< 42.00 > 
Safety Time 
— 2-145 — 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 2: Safety Protocol Requirements 


If we were to do this calculation over a number of bandwidth allocations and plot the reaction 
time vs. Standard Scanner Scan Time, we would get a graph like that shown in Figure 2-9.6. 
Giving Safety 40 - 50% of the busload provides both the Scanner and Safety a reasonable level 
of performance. 


NOTE: When Safety and Standard DeviceNet Scanning are sharing the same subnet, Safety 
EPI calculations should never allocate more than 50% of the busload. This assures that all 
Safety nodes will have sufficient opportunity to send each EPI under worse case conditions. 


Figure 2-9.6 reaction time vs. Scan Time 


Safety Time vs Scan Time - 500K 


120.00 100.0 
90.0 
400.00 ar 
70.0 
80.00 
® 
60.0 @ 
E — ~*~ Safety Time Local Output 
= 60.00 50.0 '2 —* Safety Time Remote Output 
3 § 
3 40.0 G ___ Starndard Scan Times 
40.00 30.0 
oh66 20.0 
10.0 
0.00 0.0 


80% 70% 60% 50% 40% 30% 20% 10% 
Safety Busload 


2-9.3 Bus Structure 


An example system is shown in Figure 2-9.7. A variety of architectures are possible. It shows 
devices with 1 CAN interface implementing a single CAN bus structure. This bus structure is 
made up of 2 CPUs, 1 CAN interface chips and 1 CAN transceiver. Another example is shown 
with 2 CPUs with 1 CAN controllers and 1 CAN transceiver. 


Each CAN interface shall have a unique message ID for each safety connection. 


End devices can support more than one safety connection. This may be desirable since some 
errors will cause the connection to shut down. In the case of multiple safety connections, each 
connection shall support its own safety configuration. Thus, each connection may have a 
different owner and periodic rate. 
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Figure 2-9.7 Example of DeviceNet interconnection 


SIL 3 /O Input 


Micro/CAN A 


SIL 3 Controller 


Micro/CAN A 


SIL3 1/0 Output 
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2-10 


2-10.1 


2-10.2 


2-10.3 


2-10.4 


2-10.5 


EtherNet/IP Requirements 


This section contains requirements and advisory information for Safety devices that reside 
directly on an EtherNet/IP network. 


EPI Rules for Safety Messages That Travel Over EtherNet/IP 


Safety packets that must travel over EtherNet/IP have certain restrictions based on the Safety 
format used when establishing the connection. 


Safety Connection using the base format and traveling over EtherNet/IP are restricted to EPIs 
less than 100ms. The method by which this restriction is enforced is a vendor specific 
decision. For example, the restriction could be enforced in the originator configuration 
software or in originator connection establishment checks. Vendors will be responsible for 
verifying that proper restrictions are in place. 


Default Safety I/O Service 


Safety connections support both Point-to-point and Multicast connection types, but EtherNet/IP 
has a number of system complications when Multicast services are used. It is highly 
recommended that when configuring safety connections in an originator, the safety 
configuration software should present point-to-point as the default service for all Safety 
configurations. The User should be given the option to select Multicast, but if this selection is 
not specifically made, point-to-point should be used. 


Safety EtherNet/IP devices should consider adding support for multiple point-to-point 
connections to the same safety input assembly to better facilitate the use of point-to-point. 
Duplicate IP Detection 

Safety devices that reside on EtherNet/IP shall support the IPv4 Address Conflict Detection 
mechanism defined in ODVA PUBO0127. 

Priority for Safety Connections 


EtherNet/IP Safety devices must utilize the standard EtherNet/IP Quality of Service scheme; 
see Volume 2, Chapters 3 and 5 for implementation details. EtherNet/IP Safety Devices must 
implement the QoS Object and support priority marking via DiffServ Code Points (DSCP). 
EtherNet/IP Safety devices shall use “scheduled” as the default priority for safety I/O devices. 


EtherNet/IP Networks and Safety Network Numbers 


Safety requires the assignment of Safety Network Numbers (SNN) in all Safety EtherNet/IP 
nodes. The SNN is combined with the nodes’s IP address to form a plantwide Unique Node ID 
(UNID). An example showing when a new SNN must be assigned is shown in Figure 2-10.1. 
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Figure 2-10.1 shows that nodes separated by switches and/or routers are still on the same 
network because they all have unique IP addresses. These nodes can all use the same SNN. 
However, when a subnet is created (i.e through a CIP bridge) so that IP addresses can be 
reused, anew SNN must be assigned. The indicator that a new SNN must be assigned is the 
re-use of IP addresses on the network. 


Figure 2-10.1 EtherNet/IP Networks and SNN Assignment 
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2-11 


2-11.1 


SERCOS Requirements 


This section contains requirements and advisory information for Safety devices that reside 
directly on a SERCOS network and modular SERCOS Devices that contain safety modules. 


Baseline CIP Safety on SERCOS Device 


The CIP functionality needed to implement CIP Safety in a SERCOS III device is encapsulated 
in an adaptation layer on top of the standard SERCOS III communication mechanisms. The 
SERCOS III function group “S 0 1830 Safety Connection” provides the functionality for 
configuring both explicit and I/O connections, and for exchanging data via the SERCOS 
Messaging Protocol (SMP). 


Figure 2-11.1 Baseline CIP Safety on SERCOS device 


Safety 
Supervisor Safety 
Validators 


Msg Router 


SERCOS III 7 
object 


| SERCOS Ill Network 


The CIP Safety Adaptation Layer provides CIP functionality similar to the Baseline Safety 
Device defined in Chapter 6-3. 


CIP Safety 
Adaptation 
Identity Layer 
Connection 
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2-11.2 


2-11.3 


2-11.4 


SERCOS IIl- | 


Transport Layer Requirements 


CIP Safety on SERCOS devices shall use the SERCOS Messaging Protocol (SMP) to exchange 
safety messages. SMP defines a set of messaging containers that can be transported via 
SERCOS III connections. A detailed description of the transport layer is presented in the 
SERCOS III specification (first published with V1.1.2) by SERCOS International (SI). 


Multicast Connections 


SERCOS III connections may be used to build point-to-point or multi-cast safety connections. 


CIP Safety and the SERCOS III device model 


Figure 2-11.2 shows the components of a generic SERCOS III device. There is a clear 
separation into communication- and device-related components. The communication-related 
components are defined in the SERCOS III communication profile (SCP). The SERCOS III 
Interface component represents the physical interface to the SERCOS III network, while the 
SERCOS III Slave component provides a logical interface with a SERCOS Slave Address that 
is unique to the SERCOS III Network. This structure allows for a modular device design with 
several sub-devices sharing a single physical interface. 


Figure 2-11.2 SERCOS III device model® 


Network 


ISERCOS Ill- 
Interface 


SERCOS III-Device 


In this context, “modular design” does not imply that the device hardware is modular as well. A 
monolithic device may internally be regarded as being modular if it features several 
independent sub-devices. For example, a dual axis AC drive controllers may internally be 
modeled as a single device containing two independent sub-devices with two different 
SERCOS addresses that are connected to the SERCOS III network via the same interface. 


> The multiplicity of instances in this diagram is shown conforming to the UML 2.0 syntax. “1..*” means that one or 
more instances of this entity are participating in this association. 
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2-11.5 


2-11.5.1 


In SERCOS III terms, safety functionality is modeled as a function-specific profile that 
implements one or more resources in a sub-device. This implies that a SERCOS III Device may 
contain several independent Safety Devices as defined by the CIP Safety specification (refer to 
the entity relationship diagrams in Volume 5, Chapter 2-1 and 2-2). As there is a substantial 
difference between a “Device” and a “Safety Device” in the SERCOS III context, care should 
be taken not to mix up these terms. 


Modular I/O devices are modeled as a single SERCOS III Device with usually one single sub- 
device. Each I/O module is represented by a set of function groups in this sub-device. 


UNID Assignment on SERCOS II 


CIP Safety requires the assignment of a plantwide Unique Node ID (UNID) to each safety 
device. The 10 byte UNID consists of a 6 byte Safety Network Number (SNN) combined with 
the node’s 4 byte network address (MACID on DeviceNet, IP address on EtherNet/IP). 


For a SERCOS III Safety Device, the MACID/IP address portion of the UNID shall be 
replaced by a 4 byte SERCOS III Safety Device ID (SDID). Both the SDID and the SNN shall 
be stored as attributes of the SERCOS III object. 


struct UNID 
{ 
S_SNN SNN; 
UDINT SDID; 
} 


The following rules shall be applied when assigning the UNID to a SERCOS III Safety Device. 


SERCOS III Safety Device ID 


The preceding section on the SERCOS III device model showed that it is impossible to 
uniquely identify a SERCOS III safety device in a modular SERCOS device by its network 
node address (SERCOS address, SERCO parameter S-0-1040). 


In addition, excluding the network node address from the UNID leads to a better separation of 
the standard device configuration from the safety configuration. This facilitates device 
commissioning, because a module may be moved to a different physical location after the 
safety configuration has been verified and locked. Only the non-safety-relevant parts of the 
configuration have to be adjusted to the new network topology by changing the SERCOS 
addresses. The safety layer will still ensure that only safety connections configured for this 
safety device can be established. 


Therefore, in a SERCOS III network, the SERCOS III Safety Device ID portion of the UNID 
shall be chosen by the configuration tool or set in the safety device by other means (e.g. DIP 
switches), and shall not be related to neither the SERCOS node address (e.g. node addr 8 in 
Figure 2-11.3), nor the physical position of a module on the device's local bus (e.g. slot number 
in Figure 2-11.3). 
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Figure 2-11.3 Adding a standard module to a modular device 
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It has to be assured that the cabling attached to a module is also moved to the new location 
when moving a safety module without updating the safety network configuration. The 
manufacturer of a CIP Safety on SERCOS device shall ensure this by appropriate means or by 
adding an appropriate advisory to the device’s safety manual. 
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2-11.5.2 Safety Network Number Assignment 
CIP Safety requires the assignment of Safety Network Numbers (SNN) in all CIP Safety on 
SERCOS nodes. SNN and SDID together form the UNID that has to be unique for each device 
in a safety system. Because the SDID portion of the UNID is not related to the standard 
network address of a safety device, a SNN value is not limited to the boundaries of single 
SERCOS III network. Several SERCOS III networks may use the same SNN as long as they 
belong to the same configuration segment (a group of SERCOS III networks configured by a 
single configuration tool). The configuration tool shall be responsible for assigning different 
SDID values to all safety devices in one configuration segment. 
Figure 2-11.4 Assigning Safety Network Numbers 
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3-1 


3-2 


3-2.1 


Introduction 


This chapter defines the extensions to the communication objects for CIP Safety. Safety 
connections use Class 0 connections for I/O messages. Standard Explicit message connections 
are used for the establishment of Safety I/O connections. 


Connection Object 


Several safety specific class attributes and services are defined to support CIP Safety. 
DeviceNet Safety devices use these components for connection management. 


SRS57 Safety Nodes which reside on DeviceNet shall implement the SafetyOpen and 
SafetyClose services of the Connection Object. 
Class Attribute Extensions 


The following class attributes are defined for use by CIP Safety devices. 


Attrib Need in Access | NV Name Date Description of Attribute 
ID implementation | Rule Type 

8 Optional Get Vv Connection UINT Diagnostic Counter that is a 
request error running count of SafetyOpen or 
count SafetyClose Faults.! 

9 Optional Get Vv Safety STRUCT | Status counters 
Connection of 
counters 
SafetyOpen UINT Count of successful SafetyOpen 
Request requests issued from this node to 
success count another target. 
SafetyOpen UINT Count of unsuccessful 
Request SafetyOpen requests issued from 
failure count this node to another target. 
SafetyClose UINT Count of successful SafetyClose 
Request requests issued from this node to 
success count another target. 
SafetyClose UINT Count of unsuccessful 
Request SafetyClose requests issued from 
failure count” this node to another target. 
SafetyOpen UINT Count of successful SafetyOpen 
Indication requests issued from an external 
success count originator to this node. 
SafetyOpen UINT Count of unsuccessful 
Indication SafetyOpen requests issued from 
failure count? an external originator to this node. 
SafetyClose UINT Count of successful SafetyClose 
Indication requests issued from an external 
success count originator to this node. 
SafetyClose UINT Count of unsuccessful 
Indication SafetyClose requests issued from 
failure count? an external originator to this node. 


‘Attribute 8 is the sum of the 4 failure counters in attribute 9. Having this single attribute represent connection 
errors can be used in monitoring software to efficiently monitor errors without polling the additional attribute 9 
structure. Once attribute 8 is non-zero then the monitoring software can examine attribute 9 for more details. 


“Included in class attribute 8. 
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3-2.2 


3-2.2.1 


Service Extensions 


The following services are defined for use by CIP Safety devices on DeviceNet. These 
services shall be supported by a target device on DeviceNet. The SafetyOpen and SafetyClose 
services, used in lieu of the Forward_Open and Forward_Close services of the Connection 
Manager object, inherit the identical behavior from those Connection Manager services. 


Table 3-2.1 Service Extensions 


Need in Implementation Service Name Description of Service 
Service Class Instance 
Code 
4Dhex Optional N/A Reset Counters. This service will reset class 
attributes 8 and 9 to zero. 
AE hex Required N/A SafetyClose Used to close a Safety I/O. 


connection. See the 
Forward_Close service of the 
Connection Manager object. 


S4nex Required N/A SafetyOpen! Used to establish a safety I/O 
connection. See the 
Forward_Open service of the 
Connection Manager object 


' The SafetyOpen service data shall contain a Safety Network Segment in the Connection_Path field. 


Explicit Message Response Format for SafetyOpen & SafetyClose 


The SafetyOpen and SafetyClose service responses have a common response format. This 
format contains status information for both success and failure. If the service response is a 
success, response data specific to each service is returned. If the service response is an error, a 
successful DeviceNet status, the general error code returned is OxFF, along with a variable 
amount of extended error information is returned. 


The SafetyOpen and SafetyClose Object Specific services have the following general response 
format: 


Table 3-2.2 SafetyOpen & SafetyClose response format 


Parameter Name Data Type Description of Response Parameter 
Reserved USINT Reserved 
General Status USINT One of the General Status Codes listed in Appendix B 
(Status Codes). 

Size of Additional USINT Number of 16 bit words in Additional Status array 

Status 

Additional Status ARRAY of Additional status 
UINT 

Response Data ARRAY of Response data from request or additional error data if 
octet General Status indicated an error. 


The Response Data and General/Additional Statuses for the SafetyOpen and SafetyClose 
services shall match the Response Data and General/Additional Statuses for the Forward_Open 
and Forward_Close services of the Connection Manager object, respectively. 


=3:4— 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 3: Communications Objects 


3-3 


3-3.1 


Connection Manager Object 


Safety devices shall use a Forward_Open with a Safety Network Segment to establish safety 
connections. This segment uniquely identifies the Forward_Open service as a safety 
Forward_Open. Throughout this section, the term “Safety Open” shall refer to both the 
Forward_Open service of the Connection Manager object (when containing a Safety Network 
Segment) and the SafetyOpen service of the Connection object. 


Forward_Open for Safety 


The contents of the Forward_Open service of the Connection Manager object, including the 
safety network segment, are outlined in Table 3-3.1. 


Table 3-3.1 Forward_Open with Safety Network Segment 


Parameter Name DataType Target Destination & Semantics 
/ Size 
Priority/Time_tick BYTE Connection Manager Servicing Request 
Time-out_ticks USINT Connection Manager Servicing Request 
O_to_T Network Connection ID UDINT Consuming Connection Instance:: CIP Consumed 
Connection ID 
T_to_O Network Connection ID UDINT Producing Connection Instance:: CIP Producing 


Connection ID 


Connection Serial Number UINT Value: Unique (to originator) 16-bit number 
Destination: Connection Manager Servicing Request 


Originator Vendor ID UINT Connection Manager Servicing Request 
Originator Serial Number UDINT Connection Manager Servicing Request 
Connection Timeout Multiplier USINT Producing & Consuming Connection 
Instance:Timeout Multiplier 
Reserved 3 octets 
O_to_T RPI UDINT Consuming Connection Instance::EPR 
Redundant Owner WORD Value: 0 (Safety Connections do not support 


redundancy); Destination: Connection Manager 


Connection Type Value: Point to Point; 
Destination: Connection Manager 


Priority Value: High Priority; 
Destination: Connection Manager 


Fixed/Variable Value: Fixed; 
Destination: Connection Manager 


Connection Size (in bytes) Value: Size of safety PDU including the Mode Byte, 
Actual, Complement, and Time stamp sections 
Destination: Consuming Connection 
Instance::Consumed Connection Size attribute 


(O_to_T Network Connection Parameters 


Destination: Connection Manager 


T_to_O RPI UDINT Producing Connection Instance::EPR 
g Redundant Owner WORD Value: 0 (Safety Connections do not support 
a redundancy); Destination: Connection Manager 
3 
a Connection Type Value: Point to Point; 
2 Destination: Connection Manager 
8 Priority Value: High Priority; 
3 Destination: Connection Manager 
9 Fixed/Variable Value: Fixed: 
1S 


|Parameters 
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Parameter Name DataType Target Destination & Semantics 
/ Size 
Connection Size (in bytes) Value: Size of safety PDU including the Mode Byte, 
Actual, Complement, and Time stamp sections 
Destination: Producing Connection Instance::Produced 
Connection Size 
Transport Type/Trigger BYTE Value: Safety single or multi-cast 
Destination: Validator instance 
Trigger always set to Application 
Client/Server: depending on direction 
Connection_Path_Size USINT Number of 16 bit words in the Connection_Path field 
— destination is Connection Manager servicing request. 
Note: Value included in CRC calculation does not 
include the words used for Network/Port segments 
Path Variable Consumed by intermediate bridge connection 
manager(s). Each Router Format-safety Network 
Segment immediately follows the (?-to-DeviceNet) 
bridge for which it is intended. 
Logical Segment: | Vendor ID UINT 
Electronic Key Prod Type UINT 
Prod Code UINT Value: Electronic Key of required target 
Compatible/ BYTE Servicing Connection Manager or Connection Object 
Major Rev 
Minor Rev USINT 
Application Path |_| Logical Segment: Variable; | 
Se Class word : P 
=} typically Refer to Section 3-3.8 for application path options 
< ed 
5 TOMA SCRTERE Variable; 1 | Refer to CIP Specification, Volume 1, Chapter 3, 
3 Section 3-5.5.1.9 for rules on setting/parsing these 
3 Instance word atts 
2 typically P 
=| Application Path 2 | Logical Segment: Variable; |__| Refer to Section 3-3.8 for application path options 
= Sine 
a Connection Point word Refer to CIP Specification, Volume 1, Chapter 3, 
& typically Section 3-5.5.1.9 for rules on setting/parsing these 
3 paths 
& Application Path 3. | Logical Segment: Variable; |__| Refer to Section 3-3.8 for application path options 
Connection Point word Refer to CIP Specification, Volume 1, Chapter 3, 
typically Section 3-5.5.1.9 for rules on setting/parsing these 
paths 
Config Data Data Segment: Simple | Variable Configuration data to apply to the Safety Application 
Data object identified by Config Path. 
> Safety Segment Name 0x50 Safety Network Segment 
3 Segment Size USINT Target Format Size = 54 octets 
= | Segment Format USINT Target Format = 0 
5 
E, | Network Safety Data ARRAY of | Safety Network Segment data 
3 
B 
be octet 
6 
ia 
3 
r4 
= 36 
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3-3.2 


3-3.3 


3-3.4 


Connection/Safety 
Validator Fields covered [ Config Data Segment 
by Connection Parameters covered by SCCV 
CRC 
SafetyOpen for EF Format 


Safety Originators that support the Extended (EF) format may connect to Targets with RPI’s of 
00 ms or less with either the EF format or the existing format. 


FRS361 Safety Originators that connect with an EtherNet/IP target or a DeviceNet target with 
an Ethernet/IP hop within the path and have an RPI of greater than 100 ms shall use the EF 
format. 


A variety of methods may be used to assure this. EDS files and configuration software can pre- 
configure the choice, or the originator can use a dynamic algorithm to make the determinations. 
See Section 5-6.2.6 Connection Configuration Object, Format Type Attribute for more 
information. 


The mechanism used by the originator to indicate to a target that the EF format is being 
requested will be with a new Safety Network Segment Format as defined in Appendix C. 


Originator Rules for Calculating the Connection Parameter CRC 


The Connection Parameter CRC (CPCRC) is only calculated when a connection is initially 
configured or when that connection configuration is changed (refer to the Connection 
Parameter CRC attribute in the Safety Supervisor object definition). This value remains static 
in the originator otherwise. 


The connection path size in the SafetyOpen changes value depending on whether an originator 
is sending configuration data or not. Since this field is included in the CPCRC calculation, 
originators need to calculate and maintain two values when they support the SafetyOpen 
configuration function. One value is used when configuring a device while opening the 
connection and the other value is used when just opening the connection (no configuration data 
is included). 


Also, the path size must be “pre-adjusted” to remove the path entries that get stripped off by 
routers as the Safety Forward_Open traverses each sub-net. The requirement is that the 
originator is responsible for calculating the CPCRC value based on what the SafetyOpen or 
Forward_Open will be when the target receives it so that the target can perform a simple 
calculation in all cases. 


SafetyOpen Processing Flowcharts 


The following flowcharts outline the required behavior of a target upon receipt of a 
SafetyOpen: 


A. Verify the Connection Parameter CRC. As depicted in Table 3-3.1, the connection 
parameter CRC covers the SafetyOpen fields that will be used by the target. Routers along 
the path shall not modify these fields. 

B. The target checks that the electronic key segment matches the target. See 3-3.6. 

C. Depending on the type of safety connection, the logic is shown in Figure 3-3.1 or Figure 3- 
3.2 shall be followed. 
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Figure 3-3.1 Target Processing SafetyOpen with no configuration data (Type 2 SafetyOpen). 
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Figure 3-3.2 Target Processing for SafetyOpen with configuration data (Type 1 SafetyOpen) 
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Safety Originators that do not support any other means to determine which format to connect 
with can implement the following logic to dynamically determine the format. 
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Figure 3-3.3 Originator logic to determine which format to use 
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See Section 5-6.2.6 Connection Configuration Object, Format Type Attribute for more 
information. 
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3-3.5 


3-3.6 


3-3.7 


Checks required by Multi-cast Producers with existing connections 


There is a distinct possibility that the safety parameters used in a Forward_Open or SafetyOpen 
from various consuming originators will not always be the same. A consistent set of rules must 
be used for how a Multi-cast producing target should evaluate these parameters when they 
conflict with other already established consuming connections. 


Table 3-3.2 Multi-Cast Producer Parameter Evaluation Rules 


Safety Parameter Producer Evaluation Rule if Error Response’ 
connection exists (if appropriate) 
General | Extended 
Ping_Interval EPI Multiplier Shall match existing P.LE.M. Ox01 Ox0801 
0x01 0x0012 
Time Coord Msg Min Multiplier Accept any (all can be different) N/A 
Network Time Expectation Multiplier ‘Accept any (all can be different) N/A 
Timeout_Multiplier Accept any (all can be different) N/A 
Max_Consumer_Number Shall match existing Ox01 O0x0801 
Max_Consumer_Number 0x01 0x002A 
TO RPI, ODT RPI, and Time Shall match existing connection 0x01 Ox0111 
Correction RPI RPIs 
Network Segment Type Shall match existing connection Ox01 0x803 
format 
Max_Fault_Number Accept any (all can be different) N/A 


" At the option of the device developer, another connection could also be opened rather than return an error 
response 

z3 Subsequent connection requests on an existing multi-cast connection must all be the same format as the 
existing connection. 


Electronic Key Usage for Safety 


Safety originators and targets shall meet the following requirements for use of the Electronic 
Key segment (See Table C-1.7 of The CIP Networks Library, Volume 1, Common Industrial 
Protocol (CIP)) within a Safety Open. 


FRS341 The Electronic Key segment shall be present in all SafetyOpen or Safety 
Forward_Open service requests._ 

FRS342 The Electronic Key shall always be processed by Target devices with integrity (cannot 
be confirmed externally) 


FRS344 The compatibility bit and its behavior in the Electronic Key shall be supported as 
defined by safety originators and targets, wildcards (fields set to 0) for individual fields within 
the Electronic Key shall not be supported_ 


RPI vs. API in Safety Connections 


Safety devices do not have the ability to negotiate the RPI value. Safety Targets either accept 
the requested RPI because it can be supported, or it rejects it completely. The tolerance around 
an acceptable RPI request should be +/- 128uS. 


FRS345 The T-to-O API, O-to-T API, and Time Correction API in a success response shall 
always be the same value received in the SafetyOpen 
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Application Path Construction for Safety 


CIP Specification Volume | (section 3-5.5.1.9) defines a method to construct an application 
path in a SafetyOpen for 3 references: one for configuration, one for consumed data and one for 
produced data. 


The possible path types are identified as follows: 


. - [Class] [Assembly] [Instance] [Config-instance] 

. ~ [Class] [Assembly] [Instance] [Producer-instance] 

. ~ [Class] [Assembly] [Instance] [Consumer-instance] 

. - [Class] [Assembly] [Instance] [Device-defined NULL instance)] 
- [CP] [Consumer CP] 
- [CP] [Producer CP] 

. - [CP] [Device-defined NULL CP] 


QOmMMOAmD> 


When all 3 paths referenced the same class, they are often formatted in a compressed format: 
(CP stands for Connection Point). 


[Class] [Class #] [Instance] [Instance #] [CP] [Consumer CP] [CP] [Producer CP] 


Since all three paths must reference the same class, a NULL instance value must be reserved in 
that class (by the device developers) to use the compressed form for safety. The NULL value 
will be used for the portion of the path that references the Time Coordination connection and 
configuration connection (in non-configuring originators). If a common class reference is not 
practical, the long form should be used. 


The following rules apply to SafetyOpen path construction: 


e All devices shall support the long form at a minimum 

e ANull path or Null connection point shall be used to represent the Time Coordination 
connection. 

e¢ A Null path or Null connection point shall be used for the configuration path when no 
configuration data can ever be sent on the connection. 

e On any connections, which can accept a Type | SafetyOpen, Originators shall always send 
a valid configuration path even if no configuration data is present (i.e. Type 2a). 


The “Null” path or connection point used shall be one of the module’s choosing. The method 
of making this selection in an EDS file will be via the Data Path field in the Connection 
Manager section. Devices configured by configuration applet also must provide this path. 
Safety device designers can choose the path format to specify in their EDS files from the 


following options. The possible three-path combinations for Type 1, 2a SafetyOpen on 
connections, which will accept configuration are: 


A, D, B] for the input connection, 

A, G, F] compressed format for input connections 
A, C, D] for the output connection. 

A, E, G] compressed format for output connections 


c 
c 
L 
[ 
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The possible three-path combinations for Type 2a, 2b SafetyOpen on connections, which will 
not accept configuration data are: 


[D, D, B] for the input connection, and 

[D, G, F] compressed format for input connections 
[D, C, D] for the output connection. 

[D, E, G] compressed format for output connections 


Safety Validator Connection Types 


The Safety Validator function, depending on the safety connection type provided in the 
SafetyOpen, will always require between 2-3 connection resources. The SafetyOpen contains 
the connection information to allow a target to set up these connections appropriately. This 
section will show how the connection types are determined by how the SafetyOpen must be 
filled out. 


One basic assumption is that connections for Time Coordination and Time Correction 
messages do not require a path entry since they have an implied path to the Safety Validator 
object coordinating the safety connection. The various connection scenarios are described in 
the Validator object in Chapter 5. 


The Safety Validator function can determine which connection resources will be required by 
looking at the parameter in the SafetyOpen. The various SafetyOpen parameters as well as the 
key parameters that the safety function will need to determine the types of connections is 
outlined in Table 3-3.3. Connection object instances may not be available due to target 
identifier capacity or limitations; there may be no unallocated connection identifiers 
(particularly on DeviceNet targets). Or the device may not have the processing throughput to 
handle the additional connection; etc. Safety Connection objects requires resources similar to 
standard I/O connections. 
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Table 3-3.3 Forward_Open Setting Options for Safety Connections 


OtoT TtcO Transport App App Path | App Path Max Safety Key 
Connection | Connection Type/ Path 1 oe 3! Consumer | Validator | Decision | Targets Role 
Type Type Trigger Number Connection Factors 
Type 
Point to Point | Point to Point | Application, | Vendor | Vendor Safety 1 Single-Cast | 2-PtP + Producing 
Class 0, defined | defined Input App. Produce Client Connection 
Client Null Null Path | Object (Input) Safety Data 
Path? 
Consumer 
Connection: 
Coordination 
Point to Point | Point to Point | Application, | Vendor | Safety Vendor 1 Single-Cast | 2-PtP + Consuming 
Class 0, defined | Output defined Consume: Server Connection: 
Server Null App. Null Path (Output) Safety Data 
Path Object m 
Producing 
Connection: 
Coordination 
Point to Point | Multicast Application, | Vendor | Vendor Safety 2-15 Multi-Cast 2- Producing 
Class 0, defined | defined Input App. Producer Multicast Connection: 
Client Null Null Path Object DeviceNet +1PTP+ | Safety Data 
Path Client 3 
Producing 
Connection: 
Correction 
Consuming 
Connection: 
Coordination 
Point to Point | Multicast Application, | Vendor | Vendor Safety 2-15 Multi-Cast 1- Producing 
Class 0, defined | defined Input App. Producer Multicast | Connection: 
Client Null Null Path | Object Non- +1PTP+ | safety Data + 
Path DeviceNet Client Correction 
Consuming 
Connection: 
Coordination 
Multicast Point to Point | Application, Vendor | Safety Vendor 2-15 Multi-Cast 2- Consuming 
Class 0, defined | Output defined Consumer Multicast Connection: 
Server Null App. Null Path DeviceNet. | +1 PTP+ | safety Data 
Path Object Server < 
Consuming 
Connection: 
Correction 
Producing 
Connection: 
Coordination 
Multicast Point to Point | Application, | Vendor | Safety Vendor 2-15 Multi-cast 1- Consuming 
Class 0, defined | Output defined Consumer Multicast Connection: 
Server Null App. Null Path Non- +1PTP+ | Safety Data + 
Path Object DeviceNet Server Correction 
Producing 
Connection: 
Coordination 


"Input & Output with respect to the network 


? Devices configurable via EDS must define an application Null Path in the EDS file. 
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Table 3-3.4 shows what network connection parameters to use for all three connections 


associated with each safety connection type. 
Table 3-3.4 Network Connection Parameters for Safety Connections 
Network Proper 
Target Type Connection Parameter Description 
Parameter Value 
O-to-T 0x4406 Single-cast High priority, fixed 
Single-cast T-to-O 0x4408 Single-cast High priority, fixed 
Producer a 
ome! 0x0000 Not used 
Correction 
O-to-T 0x4408 Single-cast High priority, fixed 
Single-cast T-to-O 0x4406 Single-cast High priority, fixed 
Consumer Fe 
erime: 0x0000 Not used 
Correction 
O-to-T 0x4406 Single-cast High priority, fixed 
Multi-cast T-to-O 0x240E, Multi-cast High priority, fixed 
Producer Ti 
ame 0x2406 Multi-cast High priority, fixed 
Correction 


FRS174 Successful SafetyOpen responses shall return the connection identifiers used, as well 
as the Consumer_Number assigned to the originator (always OxFFFF for single-cast 
connections). 

3-3.10 Application Reply Data in a Successful SafetyOpen Response 


The format for a SafetyOpen response for Success is the same as the Forward_Open_Reply as 
defined in CIP Specification Volume 1, Chapter 3. ~ 


The target of a SafetyOpen shall return the following data in the Application Reply field of the 


SafetyOpen response. The consumer number and PID reply data is only of significance when 
the originator is the consumer. 
Table 3-3.5 CIP Safety Target Application Reply (Size: 10 Bytes) 
Parameter Name! Data Type Description 
Consumer_Number UINT 
PID/CID STRUCT Target Identifier used to generate a PID or CID 
of: seed value. 
Target Vendor Id UINT Target’s Vendor Id 
Target Device Serial UDINT Target’s Device Serial Number 
Number 
Target Connection Serial | UINT Connection Serial Number Target assigned to the 
Number connection. The Safety Validator instance Id 
should be used. 


FRS363 When the Target of a connection using the extended format on EtherNet/IP; it shall 
use the 14-byte extended format SafetyOpen Target Application reply. 
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Table 3-3.6 — CIP Safety Extended Format Target Application Reply 


Parameter Name! Data Type Description 
Consumer_Number UINT 
PID/CID Struct of: Target Identifier used to generate a PID or CID 
seed value. 
Target Vendor Id UINT Target’s Vendor Id 
Target Device Serial UDINT Target’s Device Serial Number 
Number 
Target Connection Serial | UINT Connection Serial Number Target assigned to the 
Number connection. The Safety Validator instance Id 
should be used. 
Initial Time Stamp? UINT Used by Consumer to initialize 
Last_Time_Stamp_for_Rollover 
Initial Rollover Value” UINT Used by Consumer to initialize 
TS_Rollover_Count 


7 Consuming targets should echo back the values received in the SafetyOpen 


Table 3-3.7 SafetyOpen Target Application Reply (Size: 18 bytes) 


Parameter Name! Data Type Description 
Consumer_Number UINT 
PID/CID STRUCT of: Target Identifier used to generate a PID or CID 
seed value. 
Target Vendor Id UINT Target’s Vendor Id 
Target Device Serial Number UDINT Target’s Device Serial Number 
Target Connection Serial Number UINT Connection Serial Number Target assigned to the 


connection. The Safety Validator instance Id 
should be used. 


Time_Correction_Connection_ID UDINT Connection ID selected by the Target for the Time 
Correction connection. If chosen by the originator, 
then the value is echoed back. 


Time_Correction_API UDINT Returns same value received in the Request packet. 


' These fields are always present in the Application Reply field. When a DeviceNet target receives a SafetyOpen 
that is not multicast (thus no Time Correction connection is established) the Time_Correction_Connection_ID 
parameter shall be set to OxFFFF. If the target is not a multicast producer, the consumer number is set to OXFFFF 


FRS362 When the Target of a connection using the extended format on DeviceNet, it shall use 
the 22-byte extended format SafetyOpen Target Application reply. 


— 3-16- 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 3: Communications Objects 


3-3.11 


3-3.11.1 


Table 3-3.8 SafetyOpen Reply — for Extended Format DeviceNet Producers 


Parameter Name’ Data Type Description 
Consumer_Number UINT 
PID/CID Struct of: Target Identifier used to generate a PID or CID 
seed value. 
Target Vendor Id UINT Target’s Vendor Id 
Target Device Serial Number UDINT Target’s Device Serial Number 
Target Connection Serial Number UINT Connection Serial Number Target assigned to the 


connection. The Safety Validator instance Id 
should be used. 


Time_Correction_Connection_ID UDINT Connection ID selected by the Target for the Time 
Correction connection. If chosen by the originator, 
then the value is echoed back. 


Time_Correction_API UDINT Returns same value received in the Request packet. 


Initial Time Stamp UINT Used by Consumer to initialize 
Last_Time_Stamp_for_Rollover 


Initial Rollover Value” UINT Used by Consumer to initialize 
TS_Rollover_Count 


' These fields are always present in the Application Reply field. When a DeviceNet target receives a SafetyOpen 
that is not multicast (thus no Time Correction connection is established) the Time_Correction_Connection_ID 
parameter shall be set to OXFFFF. If the target is not a multicast producer, the consumer number is set to OxFFFF 


? Consuming targets should echo back the values received in the SafetyOpen 


Unsuccessful SafetyOpen Response for Safety 


Safety-Specific Error Responses 


The SafetyOpen has some special error cases that don’t map to the existing set of error codes, 
and extends the definition of existing error codes 


Table 3-3.9 defines new extended error codes for safety and shows the extended definition of 
existing error codes. 


Table 3-3.9 New and extended error codes for safety 


General Extended Explanation 
Status Status 
0x01 0x0105 Ownership Conflict or OUNID Mismatch. The configuration is already owned by 


another originator. 


OxO1 0x0106 Ownership Conflict or OUNID Mismatch. The output connection was already 
owned by another originator. 


Ox01 0x0205 Parameter Error in Unconnected Send Service or 
Parameter Error in SafetyOpen or SafetyClose 


0x01 Ox801 Incompatible Multi-cast RPL An existing connection has been established at a 
different RPI. 
0x01 Ox802 Invalid Safety Connection Size 
Ox01 0x803 Invalid Safety Connection Format 
0x01 0x804 Invalid Time Correction Connection Parameters 
Ox01 Ox805 Invalid Ping Interval EPI Multiplier 
Ox01 0x806 Time Coordination Msg Min Multiplier 
Ox01 Ox807 Network Time Expectation Multiplier 
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General Extended Explanation 
Status Status 
Ox01 Ox808 Timeout Multiplier 
0x01 Ox809 Invalid Max Consumer Number 
Ox01 Ox80A Invalid CPCRC 
Ox01 Ox80B Time Correction Connection Id Invalid 
0x01 Ox80C SCID Mismatch. The SCID was non-zero and did not match the value in the target 
Ox01 0x80D TUNID not set. Device is out-of-box and TUNID has not been set, so connections 
are not allowed. 
Ox01 Ox80E TUNID Mismatch. The TUNID provided does not match. The message was likely 
routed to this node in error 
Ox01 Ox80F Configuration operation not allowed 
Event/Error Matrix Table 3-3.10 provides guidance for which error codes to use for possible 
errors detected in processing a SafetyOpen. This is not intended to be an exhaustive list. 
Table 3-3.10 SafetyOpen Error Event Guidance Table 
Event Error Type General Extended 
Status Status 
The target device received a SafetyOpen | Configuration operation not allowed | 0x01 Ox080F 
request in states of Safety Supervisor 
object other than Idle and Executing. 
Device not configured 0x01 Ox110 
Safety Connection Type (name) Safety Parameter Error — Ox01 Ox315 
Invalid Invalid Connection Type 
Safety Connection Size Invalid Safety Parameter Error — 0x01 0x0802 
Invalid Safety Connection Size 
Safety Connection Format Invalid Safety Parameter Error — 0x01 0x0803 
Invalid Safety Connection Format 
Time Correction Connection Safety Parameter Error — 0x01 0x0804 
Parameters Invalid Invalid Time Correction Connection 
Parameters 
Ping Interval EPI Multiplier was out | Safety Parameter Error — 0x01 0x0805 
of the range Invalid Ping Interval EPI Multiplier 
Time Coordination Message Min Safety Parameter Error — Ox01 0x0806 
Multiplier was out of the range Time Coordination Msg Min 
Multiplier 
Time Expectation Multiplier was out | Safety Parameter Error — Ox01 0x0807 
of the range Time Expectation Multiplier 
Timeout Multiplier was out of the Safety Parameter Error — Ox01 0x0808 
range Timeout Multiplier 
Max Consumer Number not within Safety Parameter Error — OxO1 0x0809 
the limits in Multi-cast Producer Invalid Max Consumer Number 
CPCRC value in SafetyOpen and Safety Parameter Error — Ox01 0x080A. 
calculated CPCRC value. Invalid CPCRC 
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Event Error Type General Extended 
Status Status 
Time Correction Connection Id Safety Parameter Error — 0x01 0x080B 
Invalid Time Correction Connection Id 
Invalid 
RPI requested is incompatible with Incompatible Multi-cast RPI 0x01 Ox801 


previously established multi-cast 
connections 


OT RPI, T>O RPI, or Time RPI not supported 0x01 Ox0111 
Correction RPI is not supported 


All Safety Validator Instances are Connection Manager or connection | 0x01 0x0113 
being used. object cannot support any more 
connections. 


Forward_Close for Safety 


There are no additional behaviors defined for the Forward_Close service when used to close a 
Safety connection. In the following Safety Requirements, the term “Safety Close” refers to 
both the Forward_Close of the Connection Manager object and the SafetyClose of the 
Connection Object 


FRS334 The SafetyClose Service shall be used to close connections with a Safety Targets (and 
in the case of a Forward_Close all other nodes in the connection path). 


The SafetyClose request shall remove a connection from all the nodes participating in the 
original connection. 


FRS335 The SafetyClose request shall cause all resources in all nodes participating in the 
connection to be deallocated, including connection IDs, bandwidth, and internal memory 
buffers. 


FRS337 Targets receiving the SafetyClose service request shall close the connection who’s 
Originator Vendor ID, Connection Serial Number, and Originator Serial Number parameters 
match. Additional information provided by this service (ie, Connection Path) shall be ignored 
by the target. 


A SafetyClose Success reply shall be returned after the connection has been deleted at the 
target. 


FRS339 When a SafetyClose success reply is received, the originator and each intermediate 
node along the path, closes the connection and releases resources associated with that 
connection. But the originator shall also close the connection if no response is received within a 
vendor selected wait period 
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Object Model 


This chapter of the CIP Safety Networks specification contains additions to the Object Model 
that are safety specific. At this time, no such additions exist. 


All Safety objects created shall have the word “Safety” as the first word of the object name. 


~4.3- 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 4: Object Model 


This page is intentionally left blank 


~4-4— 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


Volume 5: CIP Safety 


Chapter 5: Object Library 


51s 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


Contents 


5-1 Introduction, 
5-2 Identity Objec 
5-2.1 | Changes to Common Services 
5-3 DeviceNet Object.. 
5-3.1 | DeviceNet Object Change: 
5-3.2 Quick Connect Restriction for Safety 
5-4 Safety Supervisor Object 
5-4.1 | Safety Supervisor Class Attribut 
5-4.1.1 Subclasses... 

5-4.2_ Safety Supervisor Instance Attribut 


5-4.2.1 Semantics... 14 
5-4.2.1.1 Manufacturer Name 14 
Software Revision Level 15 


Hardware Revision Level 
Manufacturer’s Seri 
Device Statu: 
Exception Status 
Exception Detail Alarm and Exception Detail Warnin; 
5-4.2.1.7.1 Common Exception Detai 
5-4.2.1.7.2. Common Exception Detail Attribute Value: 
5-4.2.1.7.3 Device Exception Detail . 
5-4.2.1.7.4 Manufacturer Exception De 
5-4.2.1.8 Alarm Enable and Warning Enable 
ek 18 

Scheduled Maintenance Expiration Timer 
Scheduled Maintenance Expiration Warning Enabl 
Configuration Lock...........0++ 


Configuration UNID (CFUNID). 19 
Safety Configuration Identifier (SCID) . 20 
Target UNID (TUNID)...... 21 
Proposed TUNID (OUNID).. 21 


Ale Output Connection Owner (OCPUNID) 
5-4.2.2 Subclasses... 
5-4.3. Safety Supervisor Common Services 
5-4.4 Safety Supervisor Object Specific Services . 
5-4.4.1 Recover Service...... 
5-4.4.2 Perform_Diagnostics Service 
5-4.4.3 Configure_Request Service ... 
5-4.4.4 Validate_Configuration Service 
5-4.4.5 Set_Password Service. 
5-4.4.6 Reset_Password Service 
5-4.4.7 Configuration_Lock/Unlock Servic: 
5-4.4.8 Mode Change Servic 
5-4.4.9 Safety_Reset Servic 
5-4.4.10 | Propose_TUNID Service 


5-4.4.11 | Apply_TUNID Servic: 32 
5-4.5 Safety Supervisor Behavior.. 34 
5-4.5.1 Safety Supervisor Object States. 34 


5-4,5.2 Safety Supervisor State Event Matri 
5-4.5.3 Effect of Locking on Device Behavior 
State Mapping of Safety Supervisor Object to Identity Object 
5 Safety Supervisor Event to Identity Object Event Mapping. 
5-4.5.6 Identity Object Event to Safety Supervisor Event Mapping. 


~5-2-— 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


5-5 Safety Validator Object 
5-5.1 Revision History .... 
5-5.2 Class Attributes... 

5-5.2.1 Safety Connection Fault Count. 
5-5.3. Instance Attributes .. eee 
5-5.3.1 Safety Validator ‘State. 

Safety Validator Type. 

Ping Interval EPI Multiplier . 

Time Coord Msg Min Multiplier... 

Network Time Expectation Multiplier. 

Timeout Multiplier 

Max Consumer Number 

Data Connection Instanc 

Coordination Connection Instance . 

Correction Connection Instance 

CCO Binding 

Max Data Ag 

Producer/Consumer Fault Counter . 
5-5.4 Class Services .. 
5-5.5 Instance Servic 

5-5.5.1 Get_Attributes_All Response 
5-5.6 | Object Behavior .. 
5-5.6.1 State Transition Diagram 
5-5.6.1.1 IDLE 

5. 1.2 Initializing 
5-5.6.1.3 Established 
5-5.6.1.4 Connection_Failed. 
5.6.2 State Event Matrix.. 

5-6 Connection Configuration Object 
5-6.1 Class Attribute Extensions 
5-6.2 Instance Attributes Additions and Extensions. 

5-6.2.1 Instance Attribute Semantics Extensions or Rest 

Connection Flags — (Attribute 2) 

CS Data Index Number — (Attribute 4) 

Connection Timeout Multiplier — (part of Attribute 5) 

Transport Class and Trigger — (part of Attribute 5) 

O=>T RPI - (part of Attribute 5)... 

O=>T Connection Parameters — (part of Attribute 5 

T=>0 RPI — (part of Attribute 5) MS 

T=>O Connection Parameters — (part of “Attribute 5) 

Connection Path — (Attribute 6)... 

Proxy Config Data Size — (part of Attribute 7) 
Proxy Config Data — (part of Attribute 7) 
5-6.2.1.12 Target Config Data Size — (part of Attribute 10) 
5-6.2.1.13 Target Config Data — (part of Attribute 10) 
5-6.2.1.14 Data Map — (Attribute 9)... sea 
5-6.2.1.14.1 | Format 0 Usage for Safety. Scanners. 
5-6.2.1.14.2 Format | Usage for Safety Scanners . 
5-6.2.1.15 Proxy Device ID 
5-6.2.1.16 Connection Disable (Attribute 12 

5-6.2.2 Special Safety Related Parameters — (Attribute 13) 

Ping Interval EPI Multiplier ... 

Time Coord Msg Min Multiplier 

Network Time Expectation Multiplier 

Timeout Multiplier... 

Max Consumer Number. 


eee 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


Target Connection UNID. 
Safety Configuration CRC (SCCRC) 
Configuration Signature (Time Stamp) 
Time Correction EPI 
5-6.2.2.10 Time Correction Connection Parameters 
5-6.2.3 Connection Parameter CRC (CPCRC) — (Attribute 14) 
5-6.2.4 Configuration Instance — (Attribute 15). 
5-6.2.5 Id Allocation... 
5-6.2.6 Format Type .. 
5-6.2.7 Format Status 
5-6.3. Object-Specific Services 
5-6.4 Common Service Extensions for Safety... 
5-6.4.1 Get Attribute All (Service Code 0x01 
5-6.4.2 Set_Attribute_All (Service Code 0x02). 
5-6.4.3 Restore (Service Code 0x15) 
5-6.5 Object Behavior 
5-7 Safety Discrete Input Point (SDIP, 
5-7.1 Revision History . 
5-7.2_ Class Attributes 
5-7.3 Instance Attribute: 
5-7.4 Common Services..... 
5-7.5  Object-specific Services 
5-7.6 Behavior ee 
5-7.6.1 Type of Safety Inputs ........ 
5-7.6.2 Safety Discrete Input Evaluation Behavior 
5-8 Safety Discrete Input Group (SDIG) 
5-8.1 | Revision History . 
5-8.2 Class Attributes 
5-8.3. Instance Attributes (Common) 
5-8.4 Common Services..... 
5-8.5  Object-specific Services 
5-8.6 Behavior 
5-9 Safety Discrete Output Point (SDOP).. 
5-9.1 Revision History . 
5-9.2 Class Attributes 
5-9.3 Instance Attributes (Common) 
5-9.4 Common Services... 
5-9.5  Object-specific Services 
5-9.6 Behavior 
5-10 Safety Discrete Output Group (SDOG 
5-10.1 Revision History...........:000 
5-10.2 Class Attributes 0.0... 
5-10.3 Instance Attributes (Common 


5-10.4 Common Services .... 
5-10.5 Object-specific Services 
5-10.6 Behavior 


5-11 
5-11.1 Revision History 
5-11.2 Class Attributes . 
5-11.3 Instance Attributes (Common 
5-11.4 Common Services .... 
5-115 Object-specific Service: 
5-11.6 Dual Channel Evaluation Behavior 


5-12 Discrete Output Point Object........... 
§-12.1 Test Output Mode for Safety Attribute 
5-12.2 Test Output Mode Semantic 


5.4 — 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


5-13. TCP/IP Object. 
5-13.1 TCP/IP Object Instance Attribute Changes 
5-14 Safety Analog Input Point Object 
5-14.1 Revision History 
5-14.2 Class Attributes . 
5-14.3 Instance Attributes. 
5-14.4 Semantics 
5-14.4.1 | Data Type, Attribute 1 
5-14.4.2 Safety Analog Input Value, Attribute 2. 
5-14.4.3 Input Range, Attribute 3... 
5-14.4.4 Input Channel Mode, Attribute 4. 
5-14.4.5 Input Point Status, Attribute 5 . 
5-14.4.6 Point Fault Reason, Attribute 6 
5-14.4.7.  5-11.5.7 Real Time Sample Period, Attribute 7. 
5-14.4.8  5-11.5.8 Input Error Latch Time, Attribute 8 
5-14.4.9 Full Scale, Attribute 9... ; 
5-14.4.10 Safe State Behavior, ‘Attribute 10 
5-14.4.11 Safe State Value, Attribute 11 
5-14.4.12 High and Low Signal, High and Low Engineering Values, Attributes 12-1 
5-14.4.13 Alarm/Warning Status, Attributes 16 
5-14.4.14 Alarm/Warning Enable, Attributes 17, 22 ...... 
5-14.4.15 Alarm/Warning Trip Points, Hysteresis and Settling Time, Attributes 18-21, 23-2 
5-14.4.16 Over Range Value, Attribute 27 
5-14.4.17 Under Range Value, Attribute 28 
5-14.4.18 Offset-A and Gain Data Type, Attributes 29, 31 
5-14.4.19 Offset-A and B, Gain and Unity Gain Reference, Attributes 30, 32 - 34 
5-14.4.20 Produce Trigger Delta, Attribute 35 . 
5-14.4.21 Subclass, Attribute 99 
5-14.5 Common Services ........... 
5-14.5.1 | Get_Attributes_All Response 
5-14.5.2  Set_Attributes_All Reques: 
5-14.6 Object-specific Services . 
5-14.6.1 Zero_Adjust and Gain_Adjust Services 
5-14.7 Behavior 
5-14.7.1 Type of Safety Inputs . 
5-14.7.2 Safety Analog Input Evaluation. 
5-15 Safety Analog Input Group Object 
5-15.1 Revision History.............. 
5-15.2 Class Attributes . 
5-15.3 Instance Attributé 
5-15.4 Semantics ....... 
5-15.4.1 | Number of Bound Instances, Attribute 1 
5-15.4.2. Bound Instances, Attribute 2 
5-15.4.3. Data Type, Attribute 3....... 
5-15.4.4 Input Range, Attribute 4 
5-15.4.5 Input Status, Attribute 5. 
5-15.4.6 Input Error Latch Time, Attribute 6 
5-15.4.7 Full Scale, Attribute 7.... 
5-15.4.8 Safe State Behavior, Attribute 
5-15.4.9 Safe State Value, Attribute 9... 
5-15.4.10 Alarm and Warning Status, Attribute 10 . 
5-15.4.11 Alarm/Warning Enable, Attributes 11, 16 
5-15.4.12 Alarm/Warning Trip Points, Hysteresis and Settling Time, Attributes 12-15, 17-20 
5-15.5 Common Services .. i 
5-15.5.1  Get_Attributes_; All Response 
5-15.5.2  Set_Attributes_All Request... 


~5-5— 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


5-15.6 Object-specific Services . 
5-15.7 Behavior 
5-15.7.1 Attribute Access Rules 
5-15.7.2 Input Status Attribute... 
5-15.7.3. Alarm and Warning Status Attribut 
5-16 Safety Dual Channel Analog Input Object.. 
5-16.1 Revision History. 
5-16.2 Class Attributes . 
5-16.3 Instance Attributes. 
5-16.4 Semantics 
5-16.4.1 | Dual Channel Mode, Attribute 1 . 
5-16.4.2. Dual Channel Evaluation Status, Attribute 2 
5-16.4.3. Discrepancy Timer, Attribute 3 
5-16.4.4 Member One, Attribute 4. 
5-16.4.5 | Member Two, Attribute 5 ts 
5-16.4.6 Discrepancy Deadband, Attribute 6 
5-16.5 Common Services .... 
5-16.5.1 | Get_Attributes_All Response 
5-16.5.2  Set_Attributes_All Reques' 
5-16.6 Object-specific Services .... 
5-16.7 Behavior 3: ssnssssuccsicvcsstenssgeansvesensieonstvee 
5-16.7.1_ | Safety Dual Channel Input Evaluation 
5-16.7.2 Discrepancy Evaluation 
5-16.7.3. Dual Channel Evaluation 


~5-6— 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


5-1 Introduction 


This section identifies and defines new safety objects that are specified for use by CIP safety 
devices. This section also defines the extensions of existing CIP objects. 
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5-2.1 


Identity Object, Class Code: 01nex 


Identity Object 
Class Code: 01hex 
This section describes changes to the Identity object to support CIP Safety. 


SRS142 All CIP safety devices shall replace the Identity object state behavior with the 
behavior defined in the Safety Supervisor object. 


Changes to Common Services 


Table 5-2.1 Identity Object Common Service Changes 


Service Need in Implementation Service Description of Service 
Code Class Instance Name 
OShex Optional Conditional* Reset Invokes the Reset Service for the Device 


*Conditional - SRS61 The Identity object Reset service shall not be supported in safety 
devices (reply to any requests with “Service Not Supported” error). The service shall be 
replaced by the Reset service defined by the Safety Supervisor. 
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5-3.1 


5-3.2 


DeviceNet Object, Class Code: 03 Hex 


DeviceNet Object 
Class Code: 03hex 


DeviceNet Object Changes 


This section defines the changes an 
safety. An attribute shall be added to allow the Safety Network Number (SNN) to be read. 
The definition for this attribute is as follows: 


Table 5-3.1 New CIP Safety-specific DeviceNet Object Instance Attribute 


additions required of the DeviceNet object to support CIP 


Attrib | Needin | Access NV Name DeviceNet Description of Semantics of Value 
ID Implem Rule Data Type Attribute 
11 Required | Get NV Safety 6 octets System-wide Attribute shall | 
Network unique number contain the SNN 
Number for the subnet this | portion of the | 


device resides on. 


TUNID in the 
Safety Supervisor. 
See Chapter 2-3.1.1 
for a complete 
definition of the 
SNN. 


SRS102 Devices implementing DeviceNet Safety shall support attributes 11 of the DeviceNet 


object. 


Quick Connect Restriction for Safety 


All CIP Safety Device shall not support the Quick Connect feature. The Quick connect 
attribute shall not be supported and shall respond to any Get/Set attribute service with the error 
code “Attribute not supported”. 
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Safety Supervisor Object, Class Code: 39 Hex 


Safety Supervisor Object 
Class Code: 39 hex 


The Safety Supervisor is the core object of CIP Safety Devices. There are two fundamental 
Safety Supervisor implementations defined: 


1. Baseline Supervisor — defined as a supervisor implementation that supports all the 
“required” attributes and services defined by this object definition. The baseline 
Supervisor includes all state machine behavior excluding state event processing for 
services not required (refer to Section 5-4.5.1). 

2. SNCT Supervisor — defined as a supervisor implementation that supports all the Baseline 
functionality plus the attributes and services that are marked “conditional” on SNCT 
support. 


SRS65 All safety devices on a CIP safety network shall support the baseline Safety 
Supervisor definition. 


Because many of the parameters in the safety supervisor object are deemed safety critical, the 
attributes of this object shall have a higher integrity than standard object data. 


SRS66 The state behavior of the Safety Supervisor object shall control the state of all CIP 
objects in a device. All CIP objects in a safety device are required to be subservient to the 
states and commands of the Safety Supervisor to manage its functions and behaviors. 


The Safety Supervisor object centralizes application object state definitions and related status 
information, exception status indications (alarms and warnings), and defines a behavior model 
which is assumed by objects identified as belonging to safety devices. That is, if a reset is 
requested of the Safety Supervisor object instance, it is performed by this object instance as 
well as all of its associated application objects. 


The Identity object shall get its state information from the Safety Supervisor object. A reset 
request to the Identity object is not supported by CIP Safety devices (refer to Section 5-2 and 
shall be replaced by a reset request to the Safety Supervisor object which has additional 
qualifiers to execute the request. Further relationships are specified in the behavior section 
below. 


Additionally, some instance attributes are reserved to allow for future extension to implement 
profiles defined for the semiconductor industry. 
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5-4.1 


5-4.1.1 


5-4.2 


Safety Supervisor Object, Class Code: 39yex 


Safety Supervisor Class Attributes 


Table 5-4.1 Safety Supervisor Class Attributes 


Attribute Need in Access Name Date Description of Attribute 
ID implementation Rule Type 

1 thru 96 These class attributes are described in Chapter 4 of CIP Common (Volume 1) 

97-98 Reserved by CIP for Future Use 

99 Conditional * Get Subclass UINT Identifies a subset of 


additional class attributes, 
services, and behaviors 


* Tf the value of Subclass is 00 which identifies "no subclass", then this attribute is OPTIONAL 
in implementation, otherwise, this attribute is REQUIRED. 


Subclasses 


Each class level subclass defines a unique meaning for an overlapping range of class attribute 
IDs and/or class service IDs. The range for subclass definitions begins at ID 96 and numbers 
downward for attributes, and ID 63-x and numbers downward for services. The subclass for a 
given class is identified by the value of its subclass class attribute. There are presently no 
subclasses defined for the class instance. 


Safety Supervisor Instance Attributes 


Table 5-4.2 Safety Supervisor Instance Attributes 


Attr Need in Access NV Name Date Description of Attribute 
ID implementation Rule Type 
1 Optional Get NV_ | Number of USINT Number of Attributes supported 
Attributes by the object instance 
2 Optional Get NV _ | Attribute List Array of | List of attributes supported by the 
USINT object instance 
3 Reserved 
4 Reserved 
5 Optional Get NV_ | Manufacturer Short ASCII Text, Max. 20 characters, 
Name String see Semantics Section 
6 Optional Get NV_ | Manufacturer Short ASCII Text, Max. 20 characters, 
Model Number | String Manufacturer specified, see 
Semantics Section 
7: Optional Get NV_ | Software Short ASCII Text, Max. 6 characters, 
Revision Level | String see Semantics Section 
8 Optional Get NV _ | Hardware Short ASCII Text, Max. 6 characters, 
Revision Level | String see Semantics Section 
9 Optional Get NV_ | Manufacturer Short ASCII Text, Max. 30 characters, 
Serial Number | String Manufacturer specified, see 
Semantics Section 
10 Optional Get NV Device Short ASCII Text, Max. 50 Characters, 
Configuration String Manufacturer Specified. Optional 
additional information about the 
device configuration 
11 Required Get Vv Device Status USINT See “Semantics” Section 
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Safety Supervisor Object, Class Code: 39 Hex 


Attr Need in Access NV Name Date Description of Attribute 
ID implementation Rule Type 
12 Required Get Vv Exception BYTE See “Semantics” Section 
Status 
13 Conditional based | Get Vv Exception STRUCT | A Structure of 3 structures 
on Exception Detail Alarm of: containing a bit-mapped 
Status Bit 7 representation of the alarm detail 
Common STRUCT 
Exception of: 
Detail 
ne Size USINT Number of Common Detail Bytes 
Conditional 
Based on Size Detail ARRAY | See “Semantics” Section 
of: 
Detail n BYTE See “Semantics” Section 
Device STRUCT 
Exception of: 
Detail 
Size USINT Number of Device Detail Bytes 
cane Detail ARRAY | See Device Profile 
Based on Size of: 
Detail n BYTE See Device Profile 
Manufacturer STRUCT 
Exception of: 
Detail 
Size USINT Number of Manufacturer Detail 
Conditional Bytes 
Based on Size Detail ARRAY | Manufacturer Specified 
of: 
Detail n BYTE Manufacturer Specified 
14 Conditional Get Vv Exception STRUCT | A Structure of 3 structures 
Based on Detail Warning | of: containing a bit-mapped 
Exception Status representation of the warning 
Bit7 detail 
Common STRUCT 
Exception of: 
Detail 
we Size USINT Number of Common Detail Bytes 
Conditional 
Based on Size Detail ARRAY | See “Semantics” Section 
of: 
Detail n BYTE See “Semantics” Section 
Device STRUCT 
Exception of: 
Detail 
Size USINT Number of Device Detail Bytes 
Detail ARRAY | See Device Profile 
Conditional of: 
Based on size Detail n BYTE See Device Profile 
Manufacturer STRUCT 
Exception of: 
Detail 
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Safety Supervisor Object, Class Code: 39pex 


Attr Need in Access NV Name Date Description of Attribute 
ID implementation Rule Type 
Size USINT Number of Manufacturer Detail 
Bytes 
Detail ARRAY | Manufacturer Specified 
yf 
Conditional - 2 — 
Based on Size Detail n BYTE Manufacturer Specified 
15 Required Set NV_ | Alarm Enable BOOL. See “Semantics” Section 
16 Required Set NV_ | Warning BOOL See “Semantics” Section 
Enable 
17 Optional Set , Time DATE___| The value of the Device’s internal 
AND_ real-time clock. 
TIME 
18 Conditional — Get NV | Clock Power USINT Describes the behavior of the 
Required if Cycle Behavior device’s internal real-time clock 
(Attribute 17) is (the “Time” attribute) during a 
supported power cycle 
0 = [default] clock always resets 
during power cycle 
1 =clock value is stored in 
nonvolatile memory at power 
down 
2 = clock is battery-backed and 
runs without device power. 
3-255 = Reserved 
19 Optional Get NV_ | Last DATE The date on which the device was 
Maintenance last serviced 
Date 
20 Optional Get NV_ | Next Scheduled | DATE The date on which it is 
Maintenance recommended that the device next 
Date be serviced 
21 Optional Get NV_ | Scheduled INT See “Semantics” Section 
Maintenance 
Expiration 
Timer 
22 Conditional — Set NV_ | Scheduled BOOL See “Semantics” Section 
Required if Maintenance 
Calibration Expiration 
Expiration is Warning 
supported Enable 
23 Optional Get NV_ | Run Hours UDINT An indication of the number of 
hours that the device has had 
power applied. 
24 | Conditional * Set only | NV | Configuration | BOOL Marks the device configuration 
by Lock contained within as Verified and 
“Configu locked, or alternatively as 
ration unverified, unlocked, and 
Lock/Un changeable. 
lock” 
Service 
Gettable 
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Safety Supervisor Object, Class Code: 


39 Hex 


Attr Need in Access NV Name Date Description of Attribute 
ID implementation Rule Type 
25 Conditional * Get NV_ | Configuration 10 octets | CFUNID - Identifies the owner of 
UNID a Device Configuration. 
all OxFF = Tool-only 
configuration. 
0 = un-owned, accept any owner 
26 Required Get NV | Safety 10 octets | The SCID is comprised of the 
Configuration Safety Configuration CRC + 
Identifier Safety Configuration Time Stamp. 
This is the signature for the 
Configuration 
27 Required Get NV _ | Target UNID 10 octets | The current UNID of the device. 
28 | Conditional" Get NV | Output 
Connection 
Point Owners. 
Number of UINT Number of OCPUNID struct 
Array Entries entries 
Output Owners | ARRAY 
of 
STRUCT 
OCPUNID 10 octets | The owner UNID for the output 
resource 
0 = un-owned, accept any owner 
(default) 
ePath Size USINT Path size, number of bytes 
Application Packed The path to owned resource (i.e. 
Resource ePath 20 04 24 01 - Assembly class, 
instance 1) 
29 Conditional * Get Vv Proposed 10 octets | The UNID value that an originator 
TUNID is attempting to set in the device. 
97-98 | Reserved by CIP for Future Use 
99 Conditional * Get NV_ | Subclass UINT Identifies a subset of additional 


instance attributes, services, and 
behaviors 


1. The nonvolatile behavior of the Time attribute is conditional on the value of the Clock Power Cycle Behavior 
attribute. 


2. If the value of Subclass is 00 which identifies "no subclass", then this attribute is OPTIONAL in implementation, 
otherwise, this attribute is REQUIRED. 
3. Safety Devices which support the SNCT interface (i.e. not configured by the Safety Open or some vendor specific 
means) shall support this attribute. 


4. Conditional - SRS135 the Output Connection Owner attribute shall be supported for all safety output assemblies, 


5-4.2.1 Semantics 


5-4.2.1.1 


Manufacturer Name 


The Manufacturer Name attribute, identifies the manufacturer of the device. 
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5-4.2.1.2 


5-4.2.1.3 


5-4.2.1.4 


5-4.2.1.5 


5-4.2.1.6 


Safety Supervisor Object, Class Code: 39 Hex 


The Manufacturer Name attribute is not guaranteed, by specification, to be unique. Therefore, it 
is not a substitute for the corresponding attribute of the Identity object and should not be used 
for identification purposes. 


Software Revision Level 
This is an ASCII coded text string representing the revision of the software corresponding to 
the specific device identified by the Identity object. 


Hardware Revision Level 


This is an ASCII coded text string representing the revision of the hardware which is identified 
by the Identity object. The manufacturer of the device must control this revision such that 
modifications to the device hardware may be tracked. 


Manufacturer’s Serial Number 


This attribute is a string representation of the vendor’s serial number of the device, formatted to 
fit most manufacturing tracking systems. It is not required that this attribute match the Identity 
object’s serial number which is used to uniquely identify the device in the network 
environment. 


Device Status 


This attribute represents the current state of the device. Its value changes as the state of the 
device changes. The following values are defined: 
Table 5-4.3 Device Status Attribute State Values 
Attribute Value State 
0 Undefined 
1 Self-Testing 
2 Idle 
3 Self-Test Exception 
4 Executing 
5 Abort 
6 Critical Fault 
7 Configuring 
8 Waiting for TUNID 
9-50 Reserved by CIP 
51-99 Device Specific 
100-255 Vendor Specific 


Exception Status 


A single byte attribute whose value indicates that the status of the alarms and warnings for the 
device. This indication may be provided in one of two methods: Basic or Expanded. 
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5-4,2.1.7 


Safety Supervisor Object, Class Code: 39 Hex 


For the Basic Method, bit seven of the Exception Status attribute is set to zero; all exceptions 
are reported exclusively through communication of this Exception Status attribute. The format 
of bits zero through six in this mode is device specific; the format may be further specified in 
an appropriate device profile specification; if it is not specified, then the format of bits zero 
through six is equivalent to that specified for the expanded method. 


For the Expanded Method, bit seven of Exception Status attribute is set to one; exceptions are 
reported through the communication of this Exception Status attribute, formatted as specified in 
the table below. In addition, the Exception Detail attributes are supported. The Exception 
Status bits are determined by a logical “OR” of the related Exception Detail bits, as indicated. 


Table 5-4.4 Exception Status Attribute Format 


Exception Status Bit Map, Bit 7 Set to 0 Exception Status Bit Map, Bit 7 set to 1 
Bit Function Function 
0 Device Specific definition (See Device | ALARM/Device-common* 
i Profile) ALARM/Device-specific 
2 ALARM/Manufacturer-specific 
3 Reserved — set to 0 
4 WARNING/device-common* 
5 WARNING(device-specific 
6 WARNING/manufacturer-specific 
7 0 = Basic Method 1 = Expanded Method 
* The alarm or warning is not specific to the device type or device type manufacturer. 


Exception Detail Alarm and Exception Detail Warning 


The formats of these two attributes are identical. Therefore, they are described together here: 


Attributes that relate the detailed status of the alarms or warnings associated with the device. 
Each attribute is a structure containing three members; these three members respectively relate 
the detailed status of exceptions that are common (i.e., not device-specific), device-specific but 
not manufacturer-specific, and manufacturer-specific. The common detail is defined below. 
The device-specific detail is defined in the appropriate Device Profile. The manufacturer- 
specific detail is defined by the manufacturer. A SIZE value of zero indicates that no detail is 
defined for the associated exception detail structure. 


Each of the three structure members is defined as a structure containing an ordered list (i.e., 
array) of bytes of length SIZE, and an unsigned integer whose value is SIZE. Each of the bytes 
in each array has a specific mapping. This mapping is formatted as 8 bits representing 8 
independent conditions, whereas a value of | indicates that the condition is set (or present), and 
a value of 0 indicates that the condition is cleared (or not present). Note that if a device does 
not support an exception detail, the corresponding bit is never set. The bitmaps for alarms and 
warnings in the corresponding attributes are structured in parallel so that a condition may have 
either alarm or warning set depending on severity. If a condition inherently cannot be both 
alarm and warning, then the parallel bit position corresponding to the other state shall remain 
"0." 
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5-4.2.1.7.1 


5-4.2.1.7.2 


5-4.2.1.7.3 


Safety Supervisor Object, Class Code: 39 Hex 


The existence of an exception detail variable structure is dependent on the value of the 
Exception Status Attribute; the existence of an exception detail variable structure is only 
required if bit seven of the Exception Status attribute is set to 1 (indicating Expanded method 
reporting) and the bit (among bits zero through six) of the Exception Status attribute 
corresponding to the particular exception type is also set to 1. 


Common Exception Detail 


This structure relates exception conditions (i.e., alarms or warnings) which are common to all 
devices. The Detail element of the structure is an ordered list (i.e., array) of bytes of length 
[SIZE] which is the value of the structure element Size. For each byte in the Detail field, all 
bits which are not identified are reserved for future standardization. 


The first byte in this attribute is CommonExceptionDetail[0]. Additional exception details, if 
provided, are named CommonExceptionDetail[1], . .. CommonExceptionDetail[SIZE]. The 
specific exception associated with each of the bitmaps is given in the table below. The SIZE for 
this revision is two (2). The criteria details for each exception condition are outside the scope of 
this document. 


Common Exception Detail Attribute Values 


Table 5-4.5 Common Exception Detail Attribute Values 


Common Exception Common Exception 

Detail [0] * Detail [1] * 
Internal diagnostic exception power supply overcurrent 
Microprocessor exception reserved power supply 
EPROM exception power supply output voltage 
EEPROM exception power supply input voltage 
RAM exception scheduled maintenance due 
Reserved by CIP notify manufacturer 
Internal real-time exception reset exception 
Reserved by CIP Reserved by CIP 


* Note that if a device does not support an exception detail, the corresponding bit is never set 


Device Exception Detail 


This structure, similar in form to Common Exception Detail, relates exception conditions 
which are specific to individual devices on the network and are defined in their respective 
device profiles. The Detail element of the structure is an ordered list (i.e., array) of bytes of 
length [SIZE] which is the value of the structure element size. For a detailed description of this 
attribute, consult the appropriate specific device profile. 
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5-4.2.1.7.4 Manufacturer Exception Detail 


This structure, similar in form to Common Exception Detail, relates exception conditions 
which are specific to the manufacturers of individual devices on the network and are defined by 
them in their product documentation. The Detail element of the structure is an ordered list (i.e., 
array) of bytes of length [SIZE] which is the value of the structure element Size. For a detailed 
description of this attribute, consult the appropriate specific device manufacturer 
documentation 


Table 5-4.6 Exception Detail Format Summary 


Detail Bit7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
Component 
Common 0 0 0 0 0 0 0 0 
Exception 
Detail Size 


Common Reserved | Real-time | Reserved | Data Non- Code Micro- Diagnostic 
Exception Fault Memory Volatile Memory | Processor 
Detail 0 Memory 


Common Reserved | Reset Notify Scheduled | PS Input | PS Reserved | PS Over 
Exception Exception Vendor Maint. Due | Voltage Output Current 
Detail 1 Voltage 


Device x x x x x x x x 
Exception 
Detail Size 


Device - - - - a oe 22 ze 
Exception 
Detail 0 


Device - - -- = - & 3s = 


Exception 
Detail n 


Manufacturer | x x x x x x x x 
Exception 
Detail Size 


Manufacturer | -- - - - - = - = 
Detail 0 


Manufacturer | -- - - ee 2 oe ee = 
Detail n 


5-4,.2.1.8 Alarm Enable and Warning Enable 


These Boolean attributes are used to enable (1) or disable (0) the Safety Supervisor object’s 
process of setting Exception bits. When disabled, corresponding bits are never set; and, if they 
were set, disabling clears them. Also, alarm and warning states are not retained; when enabled, 
bits shall be set only if the corresponding condition is true. 


The default state for these Enable attributes is enabled (1). 


5-4.2.1.9 Time 


This optional attribute represents the value of the time and date as maintained by the device’s 
real-time clock with a resolution of one millisecond. 
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The default value for the Time attribute is zero (0), corresponding to 12:00AM, January 1, 
1972, as specified by Appendix C of CIP Common. 


Scheduled Maintenance Expiration Timer 


This attribute, with a resolution of one hour, is used to cause a warning which indicates that a 
device calibration is due. An Safety Supervisor timer decrements this attribute once per hour 
while power is applied. When the attribute is no longer positive and the Scheduled 
Maintenance Expiration Warning Enable attribute is set to enabled, a Scheduled Maintenance 
Expiration Warning condition is generated. This causes the Scheduled Maintenance Due 
Warning bit to be set. 

The Scheduled Maintenance Expiration Timer attribute, when implemented, shall not wrap; 
when the attribute reaches its most negative value, it no longer decrements. The Scheduled 
Maintenance Expiration Timer, when implemented, shall continue to decrement irrespective of 
the state of the Scheduled Maintenance Expiration Warning Enable attribute. The Scheduled 
Maintenance Expiration Timer, when implemented, shall be maintained in nonvolatile memory. 


Scheduled Maintenance Expiration Warning Enable 


[his Boolean attribute is used to enable (1) or disable (0) the Safety Supervisor object’s process 
of setting the Scheduled Maintenance Due Exception bit. When disabled, the corresponding bit 
is never set; and, if it was set, disabling clears it. When enabled, the bit shall be set only if the 
corresponding condition is true. 


The default state for this Enable attribute is enabled (1). 


Configuration Lock 


SRS68 The Configuration Lock attribute, when implemented with the SNCT interface, shall be 
used to mark the device configuration as verified and to lock down the configuration; 0 = 
Unlocked (unverified and changeable), 1 = Locked (verified and not changeable). 


The default value for the Configuration Lock attribute is 0 = unlocked. Its primary use is for 
safety devices that are configured by the SNCT (i.e. not configured by the safety open). After 
the tool has configured the device and the user has validated the configuration, the software 
sets this flag to lock out any further changes. It is an option that this flag be protected by 
password which requires user verification before the configuration can be unlocked and 
changed. 


SRS199 While a device has the Configuration Lock attribute set, it shall reject 
Configure_Requests, Type | & 2 Safety Reset, and any valid Type 1 SafetyOpen. 


Configuration UNID (CFUNID) 


The Configuration UNID attribute shall be implemented as part of the SNCT interface. The 
Configuration UNID identifies the owner of the configuration in this safety device. The 
Configuration UNID attribute can be set by a number of means. 
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SRS70 The Configuration UNID attribute shall have the following special meanings assigned; 


e All octets set to 0x00 = No owner, accept any 
e All octets set to OxFF = Software Tool is the assigned owner 


SRS134 The default for the Configuration UNID shall be all octets set to 0x00 . 


SRS205 When the Configuration UNID attribute is set to “No owner, accept any”, CIP Safety 
Devices shall capture the first configuration source (Type 1 and/or Configure_Request) as the 
owner. (refer to Table 5-4.7). 


The CFUNID value is used in conjunction with the OUNID value provided in either the 
Configure_Request or a Type 1 SafetyOpen. See Table 5-4.7 for how devices respond to the 
various services based on what the CFUNID is set to at the time the service is received. For 
example, if the CFUNID is set to all OxFF, then the OUNID of the Configure_Request must 
equal this value to process the command. 


SRS71 SNCT shall always use all OxFF for the OUNID. 


Table 5-4.7 Summary of Device Behavior for various CFUNID values 


Service Value of CFUNID 
OxFF 0x00 OUNID 
Configure_Request (OxFF) Accept Accept Fail 
*from SNCT Set CFUNID=0xFF 
Configure_Request (OUNID) Fail Accept Accept only if 


Set CFUNID=OUNID | CFUNID=OUNID 
Fail otherwise 


Type :1:SafetyOpen Wl Accept Accept only if 
Set CFUNID=OUNID | CFUNID=OUNID 
Fail otherwise 


Safety Configuration Identifier (SCID) 


The Safety Configuration Identifier attribute is the signature on the safety configuration. This 
attribute is a concatenation of the Safety Configuration CRC (SCCRC) + Safety Configuration 
Time Stamp (SCTS). These values are obtained from either the Safety Open or from the Safety 
Configuration Software during configuration validation. 


SRS184 The default for SCID attribute in the Safety Supervisor shall be 0 . 


SRS198 When a device enters Configuring mode, the SCID attribute shall be set to 0 and 
maintained at this value (through power cycles) until a successful Validate has been executed. 


typedef struct _S_SCID 
{ 


DWORD dwCRC; //calculated by device 
DWORD dwTime; // set by software 
WORD wDate; 
} S_SCID; 
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Target UNID (TUNID) 
The Target UNID is an NVS attribute that reflects the UNID saved with the configuration. 


SRS107 The Target UNID attribute in the Safety Supervisor shall always reflect either the 
default or the current Target UNID saved through the UNID setting process. 


SRS116 The UNID of a device shall be stored to NVS as part of the UNID setting operation. 


SRS191 The UNID of a device shall be stored to the DeviceNet, TCP/IP or SERCOS III 
object’s Safety_Network_Number attribute as part of the UNID setting operation. 


SRS117 A device in Manufacturers default state shall have an invalid UNID value in its NVS 
(e.g. OXFF, OxFF, OxFF, OxFF, OxFF, OxFF). 


SRS118 The UNID of a device shall be read from NVS during power up and loaded into an 
attribute of the Safety Supervisor object and Safety_Network_Number attribute of the 
DeviceNet, TCP/IP or SERCOS III object. 


SRS119 If the UNID represents a valid Number (not equal to out-of-box), this number shall be 
compared to the MACID or IP Address. In case of a match the device continues its startup 
procedure. In case of a mismatch the Device transits to Abort. 


SRS120 When a device faults from a Switch-NVS setting mismatch, it shall allow either a reset 
to out-of-box, or a Recover request issued to the Safety Supervisor to clear the Abort. In both 
cases, the device shall move to the “Waiting for TUNID” state. 


SRS124 The reading of the UNID attribute in the Safety Supervisor shall be done with safety 
integrity. 


SRS125 The applying of configuration data and UNID to NVS shall be done with safety 
integrity. 


Proposed TUNID (OUNID) 


The default value for the Proposed TUNID attribute shall be all OxFFs. 
While a device is going through the “ProposeTUNIG/ApplyTUNID” process, this attribute 


reflects the value being proposed. Once the apply operation is complete, this attribute should 
be set back to the out-of-box default of all OxFFs. 


Output Connection Owner (OCPUNID) 
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This attribute is only used for safety connection to outputs. Safety connections to outputs 
define an owner to prevent errant connections from hijacking an output resource in a validated 
safety system. This owner Id identifies which originator safety device has been given 
ownership rights to this safety output connection. This parameter is obtained from the Safety 
Segment Parameters in the Safety Open. The OCPUNID value could be the same as Attribute 
25 of the Safety Supervisor (CFUNID) when the device is also configured as part of the Safety 
Open. Since device may have more than one output resource and may allow for separate 
owners of each, this attribute is arranged as a structure to allow for each resource to be 
separately maintained. The resource is identified by a Logical Segment address. 


SRS201 The default for all OCPUNIDs shall be 0 (accept any owner) with the ePath for each 
pointing to the respective resource. 


5-4,2.2 Subclasses 
Each instance level subclass defines a unique meaning for an overlapping range of instance 
attribute IDs and/or instance service IDs. The range for subclass definitions begins at ID 96hex 
and numbers downward for attributes, and ID 63hex and numbers downward for services. The 
subclass for a given instance is identified by the value of its Subclass instance attribute. There 
are no subclasses currently defined for the instances. 
5-4.3 Safety Supervisor Common Services 
Table 5-4.8 Safety Supervisor Common Services 
Service Need in Implementation Service Description of Service 
Code Class Instance Name 
OE nex Conditional | Required Get_Attributes_Single Returns the contents of the 
specified attribute 
010hex n/a Required Set_Attributes_Single Modifies an attribute value 
ODhex n/a Conditional ! Apply Applies a pending configuration to 
NV memory, and moves the device 
to the Idle state. 
15 hex n/a Optional Restore Restores last applied configuration 
in devices that support it. 
1. Safety Devices which support the SNCT interface (i.c. not configured by the Safety Open or some vendor 
specific means) shall support this service. 
Any Safety Supervisor instance service may be requested internally by the device as specified 
by the manufacturer. 
5-4.4 Safety Supervisor Object Specific Services 
Table 5-4.9 Safety Supervisor Object Specific Services 
Service Need in Implementation Service Description of Service 
Code Class Instance Name 
4Bhex Reserved 
Chex n/a Optional Recover Moves the device out of the Abort 
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Service 
Code 


Need in Implementation. 


Class 


Instance 


Service 


Name 


Description of Service 


AEB pex 


na 


Optional 


Perform_Diagnostics 


Causes the device to perform a set 
of diagnostic routines if 
appropriate 


AP hex 


na 


Conditional’ 


Configure_Request 


Moves the device to the 
Configuring State if appropriate. 
This service requires a password be 
provided to be executed. 


50nex 


na 


Conditional! 


Validate_Configuration 


Causes the device to perform a 
validation check of the pending 
configuration. This service 
requires the software to provide the 
SCID (CRC + Time Stamp) 


SThex 


n/a 


Conditional! 


Set_Password 


Used to set a password attribute in 
the Supervisor object. 


S2hex 


n/a 


Conditional! 


Configuration_Lock/ 
Unlock 


This service acts upon the 
Configuration Lock attribute in the 
Safety Supervisor. This service 
requires a password be provided to 
be executed. 


S3hex 


n/a 


Conditional? 


Mode Change 


Required for Logic devices which 
must support “executing” 
independent of I/O connections. A 
password is required to execute 
mode changes in safety devices. 


S4nex 


n/a 


Type 0 
Required, 
Type 1&2 
Conditional! 


Safety Reset 


Resets the device in a manner 
similar to the Identity object, 
except that a password is required 
to execute. 


55 hex 


n/a 


Conditional” 


Reset Password 


Used to reset the password in a 
device. Data contents of this 
message is vendor specific 


56 hex 


n/a 


Conditional’ 


Propose_TUNID 


Used to initiate the setting of the 
TUNID in an out-of-box device 


ST hex 


n/a 


Conditional* 


Apply_TUNID 


Used to complete the TUNID 
setting operation. 


1. Required for CIP Safety devices which support the SNCT interface. 


2. Conditional on supporting the password service as part of the SNCT interface 


3. Required for CIP Safety devices which support the SNCT interface and are Logic devices which must 
support “executing” independent of I/O connections. A password is required to execute mode changes 


in safety devices. 


4. Required for CIP Safety devices which support the SNCT interface but highly recommended for 
devices which are configurable by Type | SafetyOpen but don’t support the SNCT interface. 


Any Safety Supervisor instance service may be requested internally by the device as specified 
by the manufacturer. Generally, these requests will be generated as the result of an event such 
as the activation of a button or external contact closure. 


Recover Service 


Used to transition the device application objects, out of the Recoverable Fault state, to the idle 
state. This service request may be originated internally, from application objects. 
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Perform_Diagnostics Service 


Used to instruct the Safety Supervisor object to perform a diagnostic test. A diagnostic test is 
either of type common or device-dependent. Common diagnostic tests could include: RAM, 
EPROM, non-volatile memory, and communications. The structure of common type diagnostic 
tests are implementation-specific. Details of device-dependent diagnostics is outside the scope 
of this document. 


Configure_Request Service 


Used to transition the device application objects from the Abort, Execute or Idle state to the 
Configuring state. 


SRS72 When a Configure_Request is received, if the Configuration_Lock attribute is set, an 
“Object State Conflict (OxOC)” error shall be returned. 


The request contains three parameters; the password parameter contained in the Safety 
Supervisor, the Target device UNID, and the Originator UNID. These values are matched up 
against the Password, TUNID, and CFUNID in the device. The OUNID is required to allow 
the device to determine if the source is a software tool or an ACR capable originator. 


SRS73 When the Configure Request command is accepted, the device shall only accept 
configuration messages to safety relevant objects over “this connection only”. Any attempts to 
write to safety-relevant objects over other connections shall be rejected. 

SRS74 If a configuration connection fails for any reason, another Configure_Request shall be 
received (establishing a new connection source) before configuration changes can be made 
(even after a power-cycle) . 


The structure of the Configure_Request is shown in the table below. 


Table 5-4.10 Configure_Request Message Structure 


Name Data Type Description 

Service Code USINT AF ex 

Password 16 octets 

TUNID 10 octets Target Device UNID. Used to detect misrouted requests. 

OUNID 10 octets Originator Device UNID. If the originator is a software 
tool, this parameter should be set to all OxFF. If the 
originator is a device with ACR, this parameter should be 
the device’s OUNID. 


SRS143 If a TUNID, OUNID mismatch error occurs when processing a Safety Supervisor 
Configure Request, an “Invalid Parameter (0x20)” error code shall be returned. 


SRS147 If a password mismatch occurs when processing a Safety Supervisor Configure 
Request, a “Privilege Violation (OxOF)” error code shall be returned. 
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Validate_Configuration Service 


Causes the device to validate a pending configuration by executing a CRC calculation over this 
data and comparing it to the CRC provided in the message. If the CRC does not yield the same 
result, an error response as defined below is returned. Otherwise, a “success” response is 
returned. Note: This command can only be received over the connection that put the device 
into the configuration mode. The device NV saves the final SCID in Attribute 26 of the Safety 
Supervisor. 


The structure of the Validate_Configuration is shown in the table below. 


Table 5-4.11 Validate_Configuration Message Structure 


Name Data Type Description 
Service Code USINT 50hex 
SCID STRUCT of: Safety Configuration ID 
SCCRC 4 octets Proposed Safety Configuration CRC as calculated by the software. 
This is validated by the Device 
SCTS 6 octets Safety Configuration Time Stamp. This value marks the date and time 
of the configuration, which is used as a change detection mechanism. 


The structure of the Success Validate Reply is shown in the table below. 


Table 5-4.12 Validate_Configuration Success Message Structure 


Name Data Type Description 
Service Code USINT 50hex 
SCID STRUCT of: Safety Configuration ID 
SCCRC 4 octets Safety Configuration CRC as calculated by the Device. 
SCTS 6 octets Safety Configuration Time Stamp. This value is an echo of what was 
sent in the Validate request. 


SRS151 If the Safety Supervisor Validate_Configuration command does not succeed, the error 
response shall send a class defined “Validation Error” (OxDO) . The following code is defined 
as a Validation Error in the Safety Supervisor. 


Table 5-4.13 Validate_Configuration Error Code 


General Error Additional Error Name Description 
Code Error Code 
OxDO See Table 5- Validation This error is a class specific error for the Safety 
4.14 Error Supervisor and is returned in response to a 
Validate_Configuration error 


Table 5-4.14 Validate_Configuration Extended Codes 


Additional Reason Code Description 
Error Codes 


1 CRC mismatch This is the default non-specific additional code, when no other additional 
information is available and the configuration CRC does not match the 
sent value 
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2 Invalid This code can be used to indicate a parameter error if a device does 
Configuration specific validation of configuration data. This could happen for example 
Parameter even if the CRC’s matched. 
3. TUNID Not Set | This code can be used to indicate that the device is in the Waiting for 
TUNID state and needs to have its TUNID set. 


Figure 5-4.1Applying Device Configuration 


ApplyConfig(ConfigKey) 


v 


Validate 
Done? 


Yes 
v 


Set 
Mode = "Idle" 


v 


Success 


—No—> 


Failure: 


__ No Validation 
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Figure 5-4.2 Configure and Validate Processing Flowcharts 
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Set_Password Service 


v 


Success 


Causes the device to set a Password in the Supervisor. This service takes 2 parameters. The 
first one is a password parameter representing the existing password, and the second is a 
parameter representing the new parameter. When setting a password for the first time, the 
Current Password parameter is set to the Out-of-box default (zero). 


The structure of the Set_Password is shown in the table below. 
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Table 5-4.15 Set_Password Message Structure 


Name Data Type Description 
Service Code USINT Slhex 
Current Password 16 octets 
New Password 16 octets 


SRS148 If a password mismatch occurs on the current password when processing a Safety 
Supervisor Set Password command, a Privilege Violation error code (OxOF) shall be returned 


A password which is smaller than the password parameter should be right-aligned in little 
endian order to the least significant byte of the 16-octet password parameter. The unused upper 
bytes of the password parameter should be zero-filled. 


Reset_Password Service 


Provided to allow passwords in a device to be reset. The exact contents and usage has been 
made vendor specific to protect password integrity. This service requires | parameter plus a 
vendor specific data field. The required parameter is a data size field to identify the size of the 
vendor specific data field. The content of vendor data is assumed to be unique to the device 
and the means by which this service is used must be provided by each vendor. 


The structure of the Reset_Password is shown in the table below. 


Table 5-4.16 Reset_Password Message Structure 


Name Data Type Description 
Service Code USINT 55hex 
Data Size USINT Number of Vendor specific data bytes 
Vendor data Data Size Vendor data which contains data needed to cause the 
password to be reset 


FRS346 If a Data Size error occurs in the Safety Supervisor Reset_Password command, either 
error code 0x15 (too much data) or 0x13 (not enough data) shall be returned. 


FRS347 If a Vendor data mismatch occurs when processing a Safety Supervisor 
Reset_Password command, a Privilege Violation error code (OxOF) shall be returned. 


Configuration_Lock/Unlock Service 


Causes the device to modify the Configuration_Lock Attribute in the Safety Supervisor. This 
service requires a value parameter (0 = unlocked, 1 = locked), and the password parameter. 
The password parameter is compared to the stored password and will only be executed if the 
password matches. 


The structure of the Configuration_Lock/Unlock is shown in the table below. 
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Table 5-4.17 Configuration_Lock/Unlock Message Structure 


Name Data Type Description 
Service Code USINT 52hex 
Value BOOL 0 = unlocked, 1 = locked 
Password 16 octets 
TUNID 10 octets Target Device UNID. Used to detect misrouted requests. 


SRS145 If a TUNID mismatch occurs in the Safety Supervisor Configuration_Lock/Unlock 
command, the Invalid Parameter error code (0x020) shall be returned. 


SRS149 If a password mismatch occurs when processing a Safety Supervisor 


Configuration_Lock/Unlock command, a Privilege Violation error code (OxOF) shall be 
returned 


Mode Change Service 

Used by devices which need to move between Idle and Executing states regardless of its 
connection status. This command requires proper authorization to execute, so the password is 
required to execute. 


The structure of the Mode Change is shown in the table below. 


Table 5-4.18 Mode_Change Message Structure 


Name Data Type Description 
Service Code USINT S3hex 
Value BOOL 0 =Idle, 1 = Executing 
Password 16 octets 


SRS 144 If a password mismatch occurs in the Safety Supervisor Mode Change command, an 
Privilege Violation error code (OxOF) shall be returned . 
Safety_Reset Service 


Used to reset the device. The Safety_Reset service replaces the standard reset service defined 
so that it can be qualified by the password. 


SRS200 When a Type | or Type 2 Safety Reset is received, if the Configuration_Lock attribute 
is set, the “Object State Conflict error code (OxOC)” shall be returned 


The structure of the Safety_Reset is shown in the table below. 
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Table 5-4.19 Safety_Reset Message Structure 


Name Data Type Description 

Service Code USINT S4nex 

Reset type USINT See Table 5-4.20 

Password 16 octets 

TUNID 10 octets Target Device UNID. Used to detect misrouted requests. 

Attribute_Bit_Map | USINT Bit mapped parameter which indicates which attributes 
should be preserved through the reset. This parameter is 
only included when the Reset Type is 2. See 
Table 5-4.21 


SRS146 If a TUNID mismatch occurs when sending the Safety Supervisor Safety Reset 
command, the Invalid Parameter error code (0x20) shall be returned. 


SRS150 If a password mismatch occurs when processing a Safety Supervisor Safety Reset 
command, a Privilege Violation error code (OxOF) shall be returned 


Table 5-4.20 Safety Supervisor Safety Reset Types 


Value: Type of Reset 
0 Emulate as closely as possible cycling power on the device. 
1 Return as closely as possible to the default configuration, and then emulate cycling 


power as closely as possible. 


2 Return as closely as possible to the out-of-box configuration except to preserve the 
parameters indicated by the Attribute Bit Map, and then emulate cycling power as 
closely as possible. 


Table 5-4.21 Attribute Bit Map Parameter 


Bit Attribute Bit Map Assignments 
When set, preserve Soft-set MacId 


e 


When set, preserve Soft-set Baud Rate 
When set, preserve the TUNID 

When set, preserve the Password 
When set, preserve the CFUNID 
When set, preserve the OCPUNID 


Reserved, always 0 


Use Extended Map (To be defined later) 


alalulalwlrfe 


Table 5-4.22 shows how a safety device should process the various reset types based on the 
Lock/Unlock condition and safety connection status. 
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Table 5-4.22 Reset Processing Rules for Rest Types 


Possible Conditions when Reset is received 
Safety Safety No Safety No Safety 
Reset Type | Connection open | Connection open | Connections / Connections / 
/ Locked / UnLocked Locked UnLocked 
Type 0 Mode/State Error | Mode/State Error | Process & Process & 
Response Response Respond Respond 
(SRS15) (SRS15) 
Type 1 Mode/State Error | Mode/State Error | Mode/State Process & 
Response Response Error Response Respond 
(SRS15) (SRS15) 
Type 2 Mode/State Error | Mode/State Error | Mode/State Process & 
Response Response Error Response Respond 
(SRS15) (SRS15) 


Possible responses: Mode/State Error Response, Process & Respond 


Propose_TUNID Service 


The Propose_TUNID service establishes a proposed TUNID setting within the device. The 
value isn’t stored in NV memory or in the TUNID attribute until the apply service is received. 


SRS194 The Propose_TUNID service shall only be accepted when the target device is in the 
Waiting_for_TUNID state. 


Once the TUNID is successfully set, it can transition to Configuring. 


SRS195 The Macld or IP portion of the TUNID shall be matched up against the Macld of the 
DeviceNet or IP attribute of the TCP/IP object. 


The value in the Macld attribute of the DeviceNet object or IP Attribute of the TCP/IP object 
will be either what was read on the switches or what was set by a tool. In either case, the 
Macld/IP portion of the Proposed_TUNID must match this 


The structure of the Propose_TUNID service is shown in the table below. 


Table 5-4.23 Propose_TUNID Service 


Name Data Type Description 
Service Code USINT S6nex 
TUNID 10 octets Proposed Target Device UNID value. 
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SRS196 If an originator wants to cancel a propose/apply operation, sending a propose service 
with a TUNID of all OxFFs shall cancel the operation. 


TUNIDProposedHandler() 
{ 
IF (Device_State=Waiting_for_TUNID) 
THEN IF (Propose_TUNID[TUNID] != all OxFF) 
THEN IF (Propose_TUNID[TUNID_MaclId] == Macld attribute/IP Attribute) 
THEN 
TUNIDProposedAttr = Propose_TUNID[TUNID] 
NET LED Flash sequence is started 
Return Success Reply 
ELSE 
Error Code “Invalid Parameter” is returned 
ELSE // cancel propose_apply operation, returns attribute to all OxFF 
Stop NET LED Flash Sequence 
TUNIDProposedAttr = Propose_TUNID[TUNID] 
Return Success Reply 
ELSE 
Error Code “Object State Conflict” is returned 


} 
5-4.4.11_ Apply_TUNID Service 
The structure of the Apply_TUNID service is shown in the table below. 


Table 5-4.24 Propose_TUNID Service 


Name Data Type Description 
Service Code USINT SThex 
TUNID 10 octets Proposed Target Device UNID value. 


SRS197 The Apply_TUNID service shall validate the TUNID against the proposed value, 
stops the LED flashing, saves the TUNID to nonvolatile storage, updates the TUNID attribute 
in the Supervisor, and sets the proposed_TUNID attribute to all OxFFs. The Supervisor shall 
then transition to Configuring. 


{ Apply_TUNIDHandler () 
IF (Device_State=Waiting_for_TUNID) 
THEN IF {(Apply_TUNID[TUNID] != all OxFF) AND 
(TUNIDProposedAttr == Apply_TUNID[TUNID]) 
THEN 
Stop Flash Sequence 
Target_UNID = TUNIDProposedVar [TUNID] 


//NV Memory operation 

// Set SNN attribute in DeviceNet or TCP/IP object, NV Memory operation 
Safety_Network_Number = TUNIDProposedVar [SNN] 
TUNIDProposedVar[TUNID] = TUNID_OUT_OF_BOX_DEFAULT 
Return Success Reply 
Device_State = CONFIGURING 
ELSE 

Error Code “Invalid Parameter” is returned 
ELSE 

Error Code “Object State Conflict” is returned 
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Figure 5-4.3 UNID Handling during “Waiting for TUNID” 
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5-4.5 Safety Supervisor Behavior 


5-4.5.1 Safety Supervisor Object States 


Figure 5-4.4 Safety Supervisor State Diagram 
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Table 5-4.25 Safety Supervisor Events 


State Description 


Executing Device is executing, (e.g., is fully configured, has no errors, and has met vendor defined criteria). 


profile specification. 


This state, and the transitions into or out of it, shall be further specified in an appropriate device 


Self-Testing | Object instance exists and has been initialized; all attributes have appropriate initial values (as 


qualified to execute its application process. 


indicated herein and in applicable device profile specification). Exception Status bits have been 
reset. Device is performing device-specific and device type specific test to determine if it is 


Self-Test Object has detected an exception condition during self-testing. The details of the exception are 
Exception stored in the appropriate attribute values of the Safety Supervisor object. 
Idle Object and device have been initialized, successfully completed self-testing, and has a valid 


configuration. Further, the device is not executing the operational components of its device 
specific functions. Configuring and Idle are sticky states that are preserved through power cycles. 


Abort Object instance is in a Abort state; this state can only be entered due to internally generated 


events. The conditions required for exit from a recoverable fault is defined in the Event Matrix 


Waiting for Device exits Self-testing and finds the NV saved TUNID is at the out-of-box default value. It 
TUNID remains in this state until the TUNID setting sequence (i.e. propose/apply in SNCT interface) is 


successfully completed. Only then can the device be configured. 


Configuring | Object and device have been initialized, successfully completed self-testing, but does NOT have a 


valid configuration. Configuring and Idle are sticky states that are preserved through power 


cycles. 
Critical The object (and device) are in a fault state from which there is no recovery. Object services 
Fault cannot be processed. The conditions required for exit from a critical fault is outside the scope of 


this specification. 


The Safety Supervisor Status attribute value indicates the overall state of the device. It is 
updated on appropriate state transitions within the Safety Supervisor object. Attribute values 1 
through 8 represent valid states. A value of zero indicates that the Safety Supervisor state is 
unknown; conditions under which a zero value may occur are outside the scope of this 


document. 
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5-4.5.2 Safety Supervisor State Event Matrix 


Table 5-4.26 State Event Matrix for Safety Supervisor 


Event State 
Waiting for Configuring [Idle Self-Test Self-Test Executing [Abort Critical 
TUNID (Safety State) | (Safety (Safety State) [Exception (Safety State) Fault 
State) (Safety State) (Safety 
State) 
- Default Entry |-- ~~ = Transition to 
Point performs SELF TEST 
Power Applied its Self-test 
application 
process 
Not Applicable | Transition to [Not Applicable |Not Not Applicable [Not 
Last Saved [Applicable Applicable 
Self-Test State if not 
Passed out-of-box 
Else, 
Wait for 
TUNID 
Not Applicable |Set Not Applicable |Not Not Applicable |Not 
appropriate Applicable Applicable 
Exception 
Self-Test Failed Status Bits and 
Transition to 
SELF TEST 
EXCEPTION 
Validate Error OSC** | Error OSC** | Error OSC** | Error OSC** —_| Error OSC**" |Error OSC** | Error 
Propose Settings and jOsc** 
TUNID Flash Net 
LED pattern 
Save TUNID |Error OSC** Error OSC** —|Error OSC** | Error OSC** Error OSC** |Error OSC** — Error 
toNV lOsc** 
Apply TUNID |memory, 
Transition to 
Configuring 
Not Applicable |Not Set appropriate |Not Not Applicable |Not 
Exception Applicable |Exception Status | Applicable Applicable 
Condition Bits and 
Cleared Transition to 
SELF TESTING 
Transition to |Transition to Transition to |Transition to | Transition to Transition to |Transition to Ignore Event 
Critical Fault. |CRITICAL — |CRITICAL CRITICAL CRITICAL CRITICAL CRITICAL = |CRITICAL 
FAULT FAULT FAULT FAULT FAULT FAULT FAULT 
— 5-36 — 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


Safety Supervisor Object, Class Code: 39 Hex 


Event State 
Error TNS***|Stay in state [If not Locked, [Error OSC** |Error OSC** [If not If Configured: [Error 
Validate and | Transition to Locked, Transition to |OSC** 
accept ‘Configuring Drop IDLE 
Connections |-—- 
Apply Safety |Unconfigured: 
Cone State ‘Transition to 
Request Go to Configuring 
Configuring 
If 
Switch/TUNID 
mismatch 
Error OSC** 
Validate Error OSC** |Stay in state- [Error OSC** [Error OSC** [Error OSC#* [Error OSC** [Error OSC** [Error 
Configuration Store Result losc** 
Apply Request [ENF OSC** [Transition to [Error OSC** Error OSC** [Error OSC** [Error OSC** |Error OSC** [Error 
ae Idle if Valid losc** 
Error TNS*** | Apply Transition to [Error OSC** [Error OSC** [Drop Error OSC*** [Error 
configuration — |Configuring, Connections, losc** 
Transition to |proceed to Transition to 
aioe Executing if pL E/EXECU Configuring, 
Contig. Valid | rpyG Proceed to 
SafetyOpen In ine 
dependent on ks 
Profile EXECUTIN 
|G dependent 
on Profile 
Process type |Processtype If not Locked, |Process type Process type _|If not If not Locked, [Process type 
Transition to {Transition to Process type {Transition to |Transitionto Locked, Process type eae 
to 
Reset Request SELF TEST |SELFTEST  |rransition to [SELF TEST |SELF TEST Process type [transition to pee 
SELF TEST Transition t© |sELF TEST 
SELF TEST 
Internal Abort |Transition to Transition to Transition to |Error OSC** | Error OSC** Transition to |Error AIRS* Error 
Request Abort Abort Abort Abort losc** 
Error OSC** [Error OSC** | Error OSC** [Restart Transition to [Error OSC** |If Configured: [Error 
SELF TESTING Transition to |OSC** 
SELF 
TESTING [ip 
Unconfigured: 
ReCOten Transition to 
Request Configuring. 
If Switch/ 
TUNID 
mismatch 
Error OSC** 
Perform Error OSC** [Error OSC** [Transition to [Restart Transition to [Error OSC** |Performall [Error 
Diagnostics SELF TEST [opr p-ppsr_ |SELF TEST device losc** 
Request diagnostic tests 
Safety Ignore Event Ignore Event Ignore Event Ignore Event [Ignore Event Device Ignore Event — Ignore Event 
Connection Profile 
Failed Defined 
Safety 1/0 Not Possible [Not Possible [Device Profile [Ignore Event |Not Possible [Device Not Possible [Not Possible 
Connection Defined Profile 
established Defined 
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Event State 

Safety /0 Ignore Event |Ignore Event Ignore Event [Ignore Event |Not Possible {Device Ignore Event | Error 
Connection Profile OsSC** 
Deleted Defined 

Error OSC** | Error OSC** Device Profile |Error OSC** |Error OSC** Device Error OSC** — | Error. 
Mode Change Defined Profile Osc** 

Defined 

Error OSC** |Restore Error OSC** Error OSC** |Error OSC** Ignore Event |Error OSC** — |Error 

Restore Previous lOsc** 
Configuration 

Error OSC** |Error OSC** if valid, Error OSC** | Error OSC** if valid, if valid, Error 

Lock/Unlock Execute and Execute and |Execute and lOSC** 
reply reply reply 

LED Definitions for States 
Module Status |Flashing Flashing Flashing Green |Flashing Flashing Red Solid Green Flashing Red _|Solid Red 
LED Red/Green Red/Green Red/Green 


* Error AIRS = Error Response “Already in Requested Mode/State” (Code 0x0B) 

** Error OSC = Error Response “Object State Conflict” (Code 0x0C) when possible 
** Error TNS= Error Response “TUNID not Set”, 0x01 extended code or Ox80D object specific extended code 
Ignore Event:: defined as “event has no effect on the state”, no response necessary 


Any Safety Supervisor instance service may be requested internally by the device as specified 
by the manufacturer. Generally, these requests will be generated as the result of an event such 
as a diagnostic failure. 


5-4.5.3 Effect of Locking on Device Behavior 


Figure 5-4.5 shows the effect that the “locked” condition has on the ability of a device to be 
configured; devices which are locked will reject all attempts to change any configuration data 
that affects the SCID. 
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Figure 5-4.5 Configuration, Testing and Locked Relationships. 
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Table 5-4.27 shows the effect that ownership has on a device’s ability to be configured. It 
shows that owned devices can only be Type | configured by the originator that has the owner 
UNID. A locked device can never be configured regardless. 


Table 5-4.27 Configuration Owner Control vs. Device State 


Ownership Rules Configure mode Execute/Idle Mode Execute/Idle 
Unlocked Mode Locked 

Config Owned Typel accepted by Typel accepted by All Type 1 rejected 
(Config. OUNID = Owner UNID) owner only owner only 
Config Un-owned Typel accepted from Typel accepted from | All type 1 rejected 
(Config. OUNID = 0) anyone anyone 
SW Tool Owned No Type | accepted No Type | accepted All type 1 rejected 
(Config. OUNID = all OxFF) 


5-4.5.4 State Mapping of Safety Supervisor Object to Identity Object 


Table 5-4.28 describes the mapping of Safety Supervisor states to states defined for the Identity 
object. This state mapping defines the interface between these three objects. The identity 
object state attribute (if supported) shall follow this table. 
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Table 5-4.28 State Mapping of Safety Supervisor to Identity 


Safety Supervisor 
Self-Testing 


Identity 
Device Self-Testing 


Self-Test Exception Major Unrecoverable 
Idle Standby 

Configuring Standby 

Waiting for TUNID Standby 

Executing Operational 

Abort Major Recoverable 


Critical Fault Major Unrecoverable 


5-4.5.5 Safety Supervisor Event to Identity Object Event Mapping 


Table 5-4.29 describes the mapping of defined Safety Supervisor events to equivalent events 
defined for the Identity object. This event mapping defines the interface between these objects. 
This mapping is provided for reference purposes. 


Table 5-4.29 Safety Supervisor Object Event Mapping 


Safety Supervisor State Events 
map to -> 


Equivalent Identity Event 


Power Applied 


Power Applied 


Self-Test Failed 


Failed Tests 


Self-Test Passed 


Passed Tests 


Propose TUNID 


No equivalent event 


Apply TUNID 


No equivalent event 


Exception Condition Cleared 


Fault Corrected 


Critical Fault 


Major Unrecoverable Fault 


Configure Request 


Deactivated 


Validate Configuration 


No equivalent event 


Apply Configuration 


Activated 


Type 1 SafetyOpen 


No equivalent event 


Reset Request 


Reset 


Abort (Internal) 


Major Recoverable Fault 


Recover Request 


Fault Corrected 


Perform Diagnostic Request 


No equivalent event 


Safety Connection Failed 


Deactivated 


Safety Connection Established 


Activated 


Safety Connection Deleted 


No equivalent event 


Mode Change 


No equivalent event 


Restore 


No equivalent event 


Lock/Unlock 


No equivalent event 
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5-4.5.6 Identity Object Event to Safety Supervisor Event Mapping 


Table 5-4.30 describes the mapping of defined Identity objects event conditions to equivalent 
events defined for the Identity object. This event mapping shows the equivalent events between 
these objects. This mapping is provided for reference purposes only; the safety supervisor 
object is the controlling object in safety devices and only events defined by the supervisor shall 
be implemented in safety devices. 


Table 5-4.30 Identity Object Event Mapping 


Identity Events map to -> Safety Supervisor Events 
Power Applied Power Applied 
Failed Tests Self-Test Failed 
Passed Tests Self-Test Passed 
Deactivated Configure Request 
Activated Apply Configuration 
Major Recoverable Fault Abort (internal) 
Major Unrecoverable Fault Critical Fault 
Minor Fault No effect 
Fault Corrected Exception Condition Cleared 
Reset Service not supported error 
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5-5.2 


5-5.2.1 


Safety Validator Object, Class Code: 3Anex 


Safety Validator Object 
Class Code: 3Ahex 


The Safety Validator Object is designed for use in Safety devices on all CIP Networks. The 
Safety Validator contains the information necessary to coordinate and maintain reliable safety 
connections between client and server safety applications. The primary role of the Safety 
Validator function is to act as a safety transport manager of multiple low-level CIP connections 
that together form a complete safety connection. 


The device containing the Safety Validator Object can create several instances of the Safety 
Validator Object for each safety application connection point (e.g. application data assembly) 
supported by the device. 


The Safety Validator Object supports two basic safety transport types: Single-Cast and Multi- 
Cast. Each safety transport type has a defined set of low-level CIP connections that must be 

allocated along with the Safety Validator object when a safety connection is instantiated by a 
Safety Open. 


Revision History 


Safety Validator Class Description 
Revision 


Ol Initial Definition. 


Class Attributes 


Table 5-5.1 Safety Validator Class Attributes 


Attr ID Need in Access Name Data Description of Attribute Semantics 
Implem Rule Type of Value 
1 thru 7 | Optional Get See the CIP Common 


Specification, Vol. 1, 
Chapter 4-9.1 fora 
description of the optional, 
reserved class attributes. 


8 Required Get Safety Connection | UINT | Diagnostic Counter that is a 


Fault Count running count of Safety 
Connection Faults 


Safety Connection Fault Count 


SRS75 This Safety Connection Fault Count attribute in the Safety Validator shall be a running 
count (with auto-rollover) of how many times any safety connection was faulted for any 
reason. 
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Instance Attributes 


Most attribute values are derived, hard coded, or obtained from the dynamic connection 


establishment process. The only settable attribute value is the Max Data Age diagnostic. 
Table 5-5.2 Safety Validator Instance Attributes 
Attr Need in Access | NV Name Data Description of | Semantics of 
ID Implementation Rule Type Attribute Value 
1 Required Get Safety USINT State of the 
Validator Safety 
State Connection 
2 Required Get Safety USINT Safety 
Validator Validator type see semantics 
Type used in this 
instance. 
3 Optional Get Ping Interval | UINT Number that 16 to 1000 
EPI defines the 
Multiplier Ping_Count_Int 
erval fora 
particular 
connection 
4 Optional Get Time Coord STRUCT 
Msg Min of: 
Multiplier 
Time Coord USINT Size of array 
Msg Min equals Max 
Multiplier Consumer 
array size number for 
multi-cast 
producers and 1 
for single-cast 
and multi-cast 
consumer 
Time Coord | Array of: | Minimum 0- 7813 
Msg Min UINT number of 128 
Multiplier uSec 
increments it 
could take fora 
Time 
Coordination 
Message to 
traverse from 
the consumer to 
the producer 
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Attr Need in Access | NV Name Data Description of | Semantics of 
ID Implementation Rule Type Attribute Value 
5 Optional Get Network STRUCT 
Time of: 
Expectation 
Multiplier 
Network USINT Size of array 
Time equals Max 
Expectation Consumer 
Multiplier number for 
array size multi-cast 
producers and 1 
for single-cast 
and multi-cast 
consumer 
Network Array of: | Maximum 0 - 45313 
Time UINT number of 128 
Expectation uSec 
Multiplier increments that 
a consumer 
should allow 
the age of the 
safety data to 
reach 
6 Optional Get Timeout STRUCT 
Multiplier of: 
Timeout USINT Size of array 
Multiplier equals Max 
array size Consumer 
number for 
multi-cast 
producers and 1 
for single-cast 
and multi-cast 
consumer 
Timeout Array of: | Determines the | BaseFormat1-4 
Multiplier USINT number of Extended 
messages that Format 
may be lost 
before 1299. 
declaring a 
connection 
error 
7 Optional Get Max USINT Maximum 1 (Single- 
Consumer number of Cast), 2-15 
Number consumers (Multi-cast) 
allowed for the 
connection 
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Attr Need in Access | NV Name Data Description of | Semantics of 
ID Implementation Rule Type Attribute Value 
8 Optional | Get Data UINT Connection 
Connection Instance ID of 
Instance the Safety Data 
Connection 
9 Optional ' Get Coordination | STRUCT | Connection 1-max number 
Connection of: Instance IDs of | of connections 
Instance the Safety in the device 
Coordination 
Connection 
Coordination | USINT Size of array 
Connection equals Max 
Instance array Consumer 
size number for 
multi-cast 
producers and 1 
for single-cast 
and multi-cast 
consumer 
Coordination | Array of: 
Connection UINT 
Instance 
10 Optional E Get Correction UINT Connection 0 (when not 
Connection Instance ID of used) 
Instance the Time 1emax number 
Correction of connections 
Connection in the device 
11 Optional ' Get CCO Binding | UINT Instance Id of a_| 0 (when not 
CCO which used or no 
holds the bindng present) 
connection 
establishment 
settings for this 
connection. 
Only used by 
safety 
connection 
originators 
12 Required Set Max Data UINT Diagnostic 
Age which holds the 
largest Data 
Age detected in 
128 yS 
increments. 
Attribute only 
used for Safety 
Consumers 
13 Required Get Application EPATH Points to the 
Data Path application data 
attached to this 
safety 
connection. 
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Attr Need in Access | NV Name Data Description of | Semantics of 
ID Implementation Rule Type Attribute Value 
14 Optional 1 Get Vv Error Code UINT Reason for 0 if no error, 
error within else 
this instance. implementation 
specific error 
code. 
15: Conditional” Get Vv Producer/Con | STRUCT 
sumer Fault of: 
Counters 
Producer/Con | USINT Size of array 
sumer equals Max 
Counter Consumer 
Array Size number for 
multi-cast 
producers and 1 
and 1 for 
single-cast and 
multi-cast 
consumer 
Producer/Con | Array of Number of See semantics 
sumer Fault USINT Faults detected 
Counter this hour 


1. It is optional that these parameters be made publicly visible. However, all Validator instances shall have 
internal parameters which represent these variables. 


2. If the device supports the EF format, this attribute is required 


5-5.3.1 Safety Validator State 


This attribute defines the current state of the Safety Validator Object instance. Transitions in 
this state attribute reflect the current state of the object (defined below). This attribute can be 
used to determine the condition of established safety connections. 


Table 5-5.3 Safety Validator State Assignments 


Value State Name Description 


0 Unallocated In this state the Safety Validator object has either not been allocated to a 
connection or has been closed. 


1 Initializing In this state the Safety Validator object is in the process of exchanging time 
coordination information across the connection. The “safety” connection is not 
yet fully established. 


2 Established In this state the Safety Validator instance is fully established and 
producing/consuming safety data on behalf of the safety application 


3 Connection_Failed This state is entered when all connections associated with this validator have 
failed for any reason. In producers, all multi-cast consumer connections must 
have failed. As long as any consumer is still operating, the producer would 
remain in the Established state. 


4-255 Reserved 


§-5.3.2 Safety Validator Type 


This attribute defines the type of Safety Validator transport that is being used. Targets shall 
derive this value from the Safety Connection parameters in the Safety Open. 
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Table 5-5.4 Safety Validator Type, Bit field assignments 


Bit 7 Bits 0-6 
Producer(client) = 0/ Safety Connection Type 
Consumer(server) = 1 0 = unallocated 

1 = Single-cast 


2 = Multi-cast 
3-127 = Reserved 


The transports for each Safety Validator Type are depicted below. This attribute can be used to 
query a device to determine the type of connection that has been established. 


Figure 5-5.1 Safety Connection Types 
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Connection f nopaieton Connection Coordination 
on DeviceNet + {consuming Messages Type 0x02 ('conauirg _ Meeaoee 
y i 
Type 0x02 ee Connection x Connouion 
ve Yi 
/ a 
fe cifpate Data Safety Data Safety Data 
(ea Ke tion > Validator > Producing > input Data + Correction 
peltealion: | Connection Aopiestion > Validator. —t> Producing > 
Pa ppc Connection 
~ bin Correction 
im! Producing | Message 
Connection 
Multi-Cast Consumer Multi-Cast Consumer 
Connection Connection Boe 
i Coordination fi 
an, DeviceNet eis rekat Type 0x82 ae Mensege’ 
2 Ox82 roducing a roducing fat 
YP! _-—¥ Connection Connection 
/ Bx 7 Safely Data 
\ Data Safety Data 
| Application | Validator ~««——— Consuming Data + Correction: 
} Connection Application Mt Validator — Consuming = 
Si soy, Connection 
—_ ~~ 
Correction 
Consuming |, Message 
Connection 


§-5.3.3 Ping Interval EPI Multiplier 


This attribute is used as part of the Safety Validator function. This parameter is obtained from 
the Safety Segment Parameters in the SafetyOpen. The rules Multi-cast producers should 
follow for evaluating this parameter from multiple consumers is shown in Table 5-5.5. 
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5-5.3.4 


5-5.3.5 


5-5.3.6 


5-5.3.7 


5-5.3.8 


Safety Validator Object, Class Code: 3Anex 


Time Coord Msg Min Multiplier 


This attribute is used as part of the Safety Validator function. This parameter is obtained from 
the Safety Segment Parameters in the SafetyOpen. The rules Multi-cast producers should 
follow for evaluating this parameter from multiple consumers is shown in Table 5-5.5. 


Table 5-5.5 Multi-Cast Producer SafetyOpen Parameter Evaluation Rules 


Safety Parameter 


Producer Evaluation Rule 


Error Response 
(if appropriate) 


Ping Interval EPI Multiplier 


Must match existing P.LE.M. 
(1“ consumer sets it) 


Invalid Parameter 


Time_Coord Msg Min Multiplier Accept any NA 
(all can be different) 

Network Time Expectation Accept any NA 

Multiplier (all can be different) 

Timeout Multiplier Accept any NA 


(all can be different) 


Max Consumer Number 


Must match existing 


Invalid Parameter 


Max_Consumer_Number 
(1“ consumer sets it) 


Network Time Expectation Multiplier 


This attribute defines the connection reaction time associated with this connection. This 
parameter is obtained from the Safety Segment Parameters in the SafetyOpen. The rules 
Multi-cast producers should follow for evaluating this parameter from multiple consumers is 
shown in Table 5-5.5. 


Timeout Multiplier 


This attribute defines the tolerance the Safety Validator will have for lost messages before 
faulting a connection and taking a safety action. This parameter is obtained from the Safety 
Segment Parameters in the SafetyOpen. The rules Multi-cast producers should follow for 
evaluating this parameter from multiple consumers is shown in Table 5-5.5. 


Max Consumer Number 


This attribute defines the maximum number of consumers that are allowed to connect to a 
multi-cast producer (Type 82). Both Multi-cast Consumers and Producers must know this 
value to function properly. This parameter is obtained from the Safety Segment Parameters in 
the SafetyOpen. The rules Multi-cast producers should follow for evaluating this parameter 
from multiple consumers is shown in Table 5-5.5. 


Data Connection Instance 


This attribute identifies the instance of the connection object responsible for the Safety Data 
connection. This attribute is assigned as part of the connection establishment process. 
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5-5.3.9 


5-5.3.10 


5-5.3.11 


5-5.3.12 


5-5.3.13 


Safety Validator Object, Class Code: 3Anex 


Coordination Connection Instance 


This attribute identifies the instance of the connection object responsible for the Time 
Coordination connection. This attribute is assigned as part of the connection establishment 
process. 


Correction Connection Instance 


This attribute identifies the instance of the connection object responsible for the Time 
Correction connection if used. This attribute is assigned as part of the connection 
establishment process. 


CCO Binding 


This attribute identifies the Connection Configuration instance that was used to set up this 
safety connection. This binding is required to notify the CCO function when the connection is 
closed so that it can attempt to re-establish the connection. This attribute is only used in 
connection originators. This attribute may either be assigned as part of the connection 
establishment process or hard coded at design time. 


Max Data Age 


The data age of received packet data is defined as the difference between the consumer’s 
128uS clock and received Time Stamp at the time the packet is received. The Max Data 
Age attribute is the maximum value this age has reached while the connection is/was 
established. The value can be used by diagnostic tools to fine tune the Network Time 
Expectation Multiplier. 


SRS78 The Max Data Age attribute shall always reflect the largest value the connection’s data 
age reaches without exceeding the expectation multiplier. 


SRS79 If a safety connection is ever faulted and closed, the Max Data Age attribute shall be 
re-initialized to 0 when the connection is re-established. 


Producer/Consumer Fault Counter 


For connections which are using the ExtendedFormat, this attribute reflects the internal 
Producer or Consumer Fault Counters defined in Chapter 2. 


FRS375 When the connection is a EF Consuming connection, the Producer/Consumer Fault 
Counter attribute shall reflect the Consumer_Fault_Counters. When the connection is a EF 
Producing connection, the attribute shall reflect the Producer_Fault_Counter. 


The attribute is used in the conformance tests which verify proper operation of the EF fault 
detection behavior. 
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5-5.4 


5-5.5 


5-5.5.1 


5-5.6 


Safety Validator Object, Class Code: 3Anex 


Class Services 


Table 5-5.6 Safety Validator Class Services 


Service Need in 
Code Implementation Name Description of Service 
OE hex Required Get_Attribute_Single Used to read a Safety Validator Object Class 
attribute value. 
4B hex Optional Reset all error Used to reset class attribute 8 in all instances 


counters 


Instance Services 


Table 5-5.7 Safety Validator Instance Services 


Service Need in 
Code Implementation Name Description of Service 
Olhex Optional Get_Attribute_All Returns the values of all instance attributes. 
OE hex Required Get_Attribute_Single Used to read a Safety Validator Object 
attribute value. 
10nex Required Set_Attribute_Single Used to reset the Max Data Age Attribute 
AB hex Optional Reset error code Used to reset instance attribute 14 


Get_Attributes_All Response 


For required attributes only. 


Table 5-5.8 Safety Validator Get_Attributes_All Service Data 


Attribute Byte Number Name Data Type 

ID 

1 0 Safety Validator State USINT 

2 1 Safety Validator Type USINT 

3: 2,3 Ping Interval EPI Multiplier UINT 

4 variable Time Coord Msg Min Multiplier STRUCT 

= variable Network Time Expectation STRUCT 

6 variable Timeout Multiplier STruct 

7 variable Max Consumer Number USINT 

8 variable Data connection Instance UINT = 0 if not supported 
9 variable Coordination Connection Instance UINT = 0 if not supported 
10 variable Correction Connection Instance STRUCT 

il variable CCO Binding UINT = 0 if not supported 
12 variable Max Data Age UINT 

13 variable Application Path EPATH 

14 Error Code UINT 

Object Behavior 


The behavior of the Safety Validator Object is illustrated in Figure 5-5.2 and Table 5-5.9 


below. 
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Figure 5-5.2 Safety Validator State Transition Diagram 
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The Idle state is initial state entered after Power-up/Self-test. This state is the normal state 
when no connections are open or failed. 
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5-5.6.1.2 


5-5.6.1.3 


5-5.6.1.4 


5-5.6.2 


Safety Validator Object, Class Code: 3Anex 
Initializing 


For multi-cast producers, this state exists for each consumer connection handled by the 
producer. For single-cast producers and all consumers, this state relates to the entire Safety 
Validator connection. 


Established 


For multi-cast producers, this state exists for each consumer connection handled by the 
producer. For single-cast producers and all consumers, this state relates to the entire Safety 
Validator connection. 


Connection_Failed 


This state is entered when all connections associated with the Safety Validator have failed. It 
can remain in this state until either a Safety Close is received, or the connection is re- 
established from a matching originator (i.e. OUNID and Application Path match a connection 
resource). 


State Event Matrix 


Table 5-5.9 Safety Validator State Event Matrix 


State 
Event Idle Initializing Executing Connection 
Failed 
Power Applied and Self-Test Initial State - - 
Complete 
Safety Supervisor = allowing state, Validate If multi-cast If Multi-cast Match OUNID & 
Net Access State Machine = On-line, | Request & producer, producer, Application Path, 
; i Transition to | Initialize Initialize Safety | Tf match, 
New Safety Connection Requested i 2 
y a Initializing Safety Connection Transition to 
Connection Initializing 
Time Coordination Handshake - Transition to Tf multi-cast - 
Complete Executing producer, 
New Consumer 
On-line 
Consumer fails in Multi-cast producer | -- Flash NET Flash NET - 
while other consumers still on-line status LED status LED Red 
Red 
All connections Failed ae: Transition to Transition to Flash NET status 
Connection Connection LED Red 
Failed Failed 
Matching Consumer Connection - Transition Transition Transition to 
Request (i.e. OUNID and Application Consumer to | Consumer to 
path match a failed consumer Initializing Initializing 
connection) 
Safety Close Received Success Reply, | Success Reply, | Success Reply, | Success Reply, 
Stay in Idle Transition to Transition to Transition to Idle 
Idle Idle 
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Safety Validator Object, Class Code: 3Anex 


Table 5-5.10 State mapping between Safety Supervisor and Safety Validator objects 


Safety Supervisor 


Safety Validator 


Self-Testing 


Idle 


Self-Test Exception 


Idle 


Waiting for TUNID 


Idle 


Idle 


Idle**, Initializing Executing, or 
Connection_Failed 


Configuring 


Idle 


Executing Idle**, Initializing or Executing, 
or Connection_Failed 

Abort Idle 

Critical Fault Idle 


**SRS80 A Safety Validator shall only accept connections when the Safety Supervisor is in 
the state that can accept connections which is device dependent (i.e. Executing only, or 
Execute/Idle) . A Safety Validator instance could be Idle while another Safety Validator is still 


active. 
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5-6.1 


5-6.2 


Connection Configuration Object, Class Code: F3ex 


Connection Configuration Object 
Class Code: F3hex 


This section defines the extensions to the Connection Configuration Object, Class 0xF3 for 
CIP Safety. (Also see CIP Common, Chapter 5 for the complete object definition.) 


Class Attribute Extensions 
The following class attributes are defined for use by CIP Safety devices. 


Table 5-6.1 Connection Configuration Object Class Attribute Extensions 


Attribute Need in Access Name Data Type Description of Attribute 
ID Implem Rule 
9 Conditional! Set Edit UDINT Created and used by configuration 
Signature software to detect modifications to the 
instance attribute values 


1. This attribute is only required in devices not using the Safety SNCT interface. 


Instance Attributes Additions and Extensions 
The following instance attributes and changes are defined for use by CIP Safety devices. 


Table 5-6.2 Connection Configuration Object Instance Attribute Additions/Extensions 


Attr Need in Access | NV Name Data Description of Semantics of 
ID Implemen- Rule Type Attribute Value 
tation 
9 Required Set NV_ | Data Map STRUCT 
of 
format_number | UINT This number 2-99 
determines the map | Reserved 
format used. 
100 - 199 
Vendor 
Specific 
All other 
values are 
Reserved. 


Data_Map UINT Size, in bytes, of 
data_size Map information 
Data_Map_ Array of | Data Map format 
dati ciel data based on 


Format number. 
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Connection Configuration Object, Class Code: F3ex 


Attr Need in Access | NV Name Data Description of Semantics of 
ID Implemen- Rule Type Attribute Value 
tation 
10 Optional Set NV | Target Config STRUCT 
Data of 
config_data_size | UINT Length of 
config_data 
in bytes. 
config_data Array of | Target Config data 
octet 
ll Optional Set NV | Proxy Device ID | STRUCT 
of 
vendor_id UINT Vendor ID 
product_type UINT Device Type 
product_code UINT Product Code 
major_rev USINT Major revision 
minor_rev USINT Minor revision 
12 Conditional’ | Set NV_ | Connection BOOL 0 —connection is 
Disable enabled. 
1 — connection is 
disabled. 
When an Open 
service is 
received this 
value shall be set 
to0. Whena 
Close or Stop 
service is 
received this 
value shall be set 
tol. 
13 Conditional’ | Set NV | Safety STRUCT 
Parameters of 
reserved USINT Reserved Shall be zero 
reserved USINT Reserved Shall be zero 
Configuration UDINT CRC32 over the This value 
CRC target device calculated by the 
configuration data configuration 
in Attribute 7 & 10 | software on the 
data in Attr. 7 
&10 after the 
configuration is 
applied 
Configuration DATE 
Signature AND 
TIME 
Time Correction | UDINT 
EPI 
Time Correction | WORD 
Connection 
Parameters 
Target UNID 10:octets UNID of target 
device 
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Connection Configuration Object, Class Code: F3 ex 


Attr Need in Access | NV Name Data Description of Semantics of 
ID Implemen- Rule Type Attribute Value 
tation 
Reserved space 10:octets_ | All zeros Allows FW to 
for Originator casily stuff 
UNID OUNID into 
safety segment 
Ping Int EPI UINT 
Mult 
Time Coord UINT 
Msg Min Mult 
Net Time Exp UINT 
Mult 
Timeout USINT 
Multiplier 
Max Consumer USINT 
Number 
14 Conditional’ | Get NV_ | Connection UDINT CRC-32 over the This value is 
Parameter CRC connection calculated by this 
parameters used in a | device only once 
Safety Open when the 
configuration is 
applied. It must 
be readable by 
configuration 
software 
15 Conditional’ | Set NV_ | Configuration UINT Which object has = 0 when no 
Instance configuration for object assigned 
this node 
16 Conditional’ | Set NV _ | Id Allocation BOOL When cleared, the 0: allocate the Id 
originator will for produced 
allocate the network | connections 
Ids for its produced | (default) 
connechons 1; ask target for 
produced Ids 
17 Conditional’ | Get Target UINT The instance # of 0 when 
Connection the Target’s Safety connection is not 
Serial Number Validator. established 
Target Connection 
Serial Number 
returned during 
connection 
establishment. 
Read by diagnostic 
tools 
20 Conditional? | Set NV_ | Format Type USINT _ | Defines which 0 = Auto (default) 
format to use in 1 = “Base” 
connecting to a te 4 
target 2 =“Extended’ 
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Connection Configuration Object, Class Code: F3 Hex 


Attr Need in Access | NV Name Data Description of Semantics of 
ID Implemen- Rule Type Attribute Value 
tation 
21 Conditional’ | Get NV _ | Format Status USINT Indicates which 0 = Auto 
format is currently 1 = “Base” 
in use when the » 
Format Type is 2p Extended 
Auto (or if no OxFF = “conflict 
agreement on a detected” 
format could be 
obtained) 
22 Conditional’ | Set NV_ | Max Fault UINT Used by both Default = 5. 
Number producers and A value of 0 
consumers to indicates 


determine how 
many erroneous 
packets can be 
dropped before a 
connection must be 
closed. 


connections must 
be closed on any 
detected error. 


“This attribute is required for a device which supports safety connections; otherwise this attribute is optional 


‘This attribute is required for a device which supports the Extended format; otherwise this attribute is optional 


5-6.2.1 Instance Attribute Semantics Extensions or Restrictions for Safety 


5-6.2.1.1 Connection Flags —- (Attribute 2) 


Table 5-6.3 Connection Flags Attribute Definition 


Bit Meaning 
0 Connection Direction 
0 = Originator 
1 = Target 


1-3 O->T Real time transfer format 

0 = Use 32-bit Run/Program header to indicate idle mode. 
1 = Use zero data length packet to indicate idle mode. 

2 = None. Connection is pure data and is modeless. 
leartbeat. 

4 = Reserved for future use 

5 = Safety Format 


Other values are reserved for future use. 


4-6 T->O Real time transfer format 

0 = Use 32-bit Run/Program header to indicate idle mode. 
1 = Use zero data length packet to indicate idle mode. 

2 = None. Connection is pure data and is modeless. 

3 = Heartbeat. 

4 = Reserved for future use 

5 = Safety Format 


Other values are reserved for future use. 
7-15 | Reserved 
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5-6.2.1.2 


5-6.2.1.3 


5-6.2.1.4 


Connection Configuration Object, Class Code: F3 ex 


Connection Flag usage for safety 
Connection Flags are defined as follows: 


Bit 0: Connection Direction. 
Always 0 = Originator of connection 
Bit 1-3: O=T Real time transfer format 
Always 101 = Safety Format 
Bit 4-6: T=>O Real time transfer format 
Always 101 = Safety Format 
Bit 7-15: Not used. 
Always 0. 
Value: 0x005A = Originator 
0x005B = Target 


CS Data Index Number - (Attribute 4) 
CS Data Index usage for safety 


Not Used. Must be 0xFFFFFFFF 


Connection Timeout Multiplier — (part of Attribute 5) 


Connection Timeout Multiplier usage for safety 

It is used by the producer and consumer to timeout any of the 3 standard connections. It is 
used by the consumer of the connection to determine if the connection should timeout. The 
timeout value for the connection is defined as: 


Connection RPI * (CTM + 1) *4 


Range: 0to7 
0 = (x4), 1 = (x8), 2 = (x12), 3 = (x16), 4 = (x20), 5 = (x24), 6 = (x28), 7 = (x32) 
Value: Always 1 (x8) 


Transport Class and Trigger — (part of Attribute 5) 


Transport Class and Trigger usage for safety 
This attribute defines the transport class and the trigger as defined below: 


Bit 0-3: Transport Class 
Always 0000 — Class 0 
Bit 4-6: Production Trigger 
Always 010 (Application) 
Bit 7: Direction 
0 = Client (TO used for data, i.e. input device) 
1 = Server (OST used for data, i.e. output device) 
Value: 0x20 (0010 0000) for an Input Connection 
OxAO (1010 0000) for an Output Connection 
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5-6.2.1.5 


5-6.2.1.6 


Connection Configuration Object, Class Code: F3 ex 


O=>T RPI - (part of Attribute 5) 


O=>T RPI usage for safety 
If direction is 0 (Client / T=O), then this is the Time Coordination RPI and the T>O RPI is 
the Data Production RPI. 


If direction is 1 (Server /O=T), then this is the Data Production RPI and the T>O RPI is the 
Time Coordination RPI. 


Time Coordination RPI 
Range: 100 to 100,000,000 us 


Ping Interval EPI Multiplier * Data Production RPI 


Data Production RPI 
Range: 100 to 1,000,000 us 


O=>T Connection Parameters - (part of Attribute 5) 


O=>T Connection Parameters usage for safety 

Defined as follows: 

Bits 0-8: Connection size (in bytes). 

If the direction is 1 (Server / O=T), it is the size of the Safety Message: 


If Data Size is 1-2 bytes: Data Size = application data size + 6 bytes 


If Data Size is 3-250 bytes: Data Size = (application data size * 2) + 8 bytes 


If the direction is 0 (Client / T =O), it is the size of the Time Coordination Message (6 bytes). 
Range: 7-510 


Bit 9: Fixed / Variable 
Always 0 (Fixed) 
Bit 10-11: Priority 
Always 01 (High) 
Bit 12: Reserved 
Always 0 
Bit 13-14: Connection Type 
Always 10 (Point to Point) 
Bit 15: Redundant Owner 
Always 0 (Safety doesn’t support Redundancy) 


— 5-59 - 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


5-6.2.1.7 


5-6.2.1.8 


Connection Configuration Object, Class Code: F3 ex 
T=>0 RPI - (part of Attribute 5) 
T=>O RPI usage for safety 


If direction is 0 (Client / TO), then this is the Data Production RPI and the OST RPI is the 
Time Coordination RPI. 


Tf direction is! (Server /O=>T), then this is the Time Coordination RPI and the OST RPI is 
the Data Production RPI. 


Value: Refer to O>T RPI 


T=>O Connection Parameters — (part of Attribute 5) 


T=>O Connection Parameters usage for safety 
Defined as follows: 
Bits 0-8: Connection size (in bytes). 


If the direction is 0 (Client / T=), it is the size of the Safety Message. 
For Single-cast, see OT Connection Parameters. 


For Multi-cast with a Data Size of 1-2: Data Size = application data size + 12 

For Multi-cast with a Data Size of 3-247: Data Size = (application data size * 2) + 14 
Multi-cast calculations shall include the Time Correction Section. This is required for all 
multi-cast connections to ensure the proper calculation of the CPCRC in the SafetyOpen. The 
value is fixed up by the Target Device. 

Tf the direction is 1 (Server / O>T ), it is the size of the Time Coordination Message (6 bytes). 


Range: 508 


Bit 9: Fixed / Variable 
Always 0 (Fixed) 


Bit 10-11: Priority 
Always 01 (High) 

Bit 12: Reserved 
Always 0 

Bit 13-14: Connection Type 


01 (Multi-cast) 
10 (Point to Point) 
Default: 10 (Point to Point) 
Bit 15: Redundant Owner 
Always 0 (Safety doesn’t support Redundancy) 
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5-6.2.1.9 


5-6.2.1.10 


5-6.2.1.11 


5-6.2.1.12 


5-6.2.1.13 


Connection Configuration Object, Class Code: F3ex 


Connection Path — (Attribute 6) 


Connection Path Size - Number of 16-bit words stored in Connection Path. This path shall be 
adjusted to remove the size of the bridge path elements when the CPCRC is calculated (i.e. the 
size used in the calculation must be the value the target will see after the bridge(s) have 
stripped away their segments and appropriately adjusted this size). 


Connection Path usage for safety 
The connection paths associated with the connection in the following order: (1) Bridge Path, 
(2) Configuration Path, (3) Consumption Path, and (4) Production Path. 


The bridge path (1) shall be separated by the originator from the application path 2, 3, & 4 at 
the time the SafetyOpen is built and when the CPCRC is calculated. 


Bridge Path 
Valid path constructed for the route between the originator and target. 


Configuration Path 
Valid path if configuration data is present in Attributes 7 or 8, or Null path otherwise. The path 
in all cases comes from the Target Applet (i.e. EDS File). 


Target Consumption Path 
Valid path if direction 1 (Server /O=>T) or Null Path otherwise. The path in all cases comes 
from the Target Applet (i.e. EDS File). 


Target Production Path 
Valid path if direction is 0 (Client / T=>O) or Null Path otherwise. The path in all cases comes 
from the Target Applet (i.e. EDS File). 


Proxy Config Data Size — (part of Attribute 7) 


Usage is optional for Safety, zero if not used 


Proxy Config Data — (part of Attribute 7) 


Usage is optional for Safety and should be concatenated with the contents of Target Config 
data 


Target Config Data Size - (part of Attribute 10) 


Target Config Data Size usage for safety 
Number of bytes stored in Target Config Data (below) 


Range: 1 to <Max Allowable Configuration Size> 


Target Config Data - (part of Attribute 10) 


Target Config Data usage for safety 
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5-6.2.1.14 


5-6.2.1.14.1 


Connection Configuration Object, Class Code: F3 ex 


Used to store the target device’s configuration data 


Data Map - (Attribute 9) 


This attribute name has been changed from “Implementation Defined” to “Data Map” to reflect 


its primary use; to map the application data to this connection. What follows is a set of map 
formats that are currently defined in the standard range. The vendor specific range is still 
available to be used for special map formats. 
Table 5-6.4 Data Map Formats 
Format Format Name Data Map Data Map Data Comment 
Number Data Size 
(in octets) 
0 Open Scanner 4 octets See Table 5-6.5 | Simple format which maps data in word 
Format granularity to input and output image 
tables 
1 Byte-Index 4 octets See Table 5-6.6 Simple format which maps data in byte 
Scanner Format granularity to input and output image 
tables 
2-99 Reserved 
100-199 | Vendor specific 
200 - Reserved 
65535 
Format 0 Usage for Safety Scanners 
Contains the Map Data structure using the format described in Map Format Type. 


Table 5-6.5 Map Data for Format 0 


Name Data Description 
Type 
Originator to Target Data UINT The offset, in 16 bit units, in the originator to target image table 


image offset 


Target to Originator Data UINT The offset, in 16 bit units, in the target to originator image table 
image offset 


Values: 
O=T Data Image Offset 


Tf the direction is 0 (Client /T=O): Always 0. 
If the direction is 1 (Server / O=T): Word offset into the Safety Output Data Table. 


T=O Data Image Offset 


If the direction is 0 (Client / TO): Word offset into the Safety Input Data Table. 
Tf the direction is 1 (Server /O=T): Always 0. 
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Connection Configuration Object, Class Code: F3ex 


5-6.2.1.14.2 Format 1 Usage for Safety Scanners 
Contains the Map Data structure using the format described in Map Format Type. 


Table 5-6.6 Map Data for Format 1 


Name Data Description 
Type 
Originator to Target Data UINT The offset, in 8 bit units, in the originator to target image table 
image offset 
Target to Originator Data UINT The offset, in 8 bit units, in the target to originator image table 
image offset 
Values: 
O=T Data Image Offset 


If the direction is 0 (Client / TO): Always 0. 
If the direction is 1 (Server / O=T): byte offset into the Safety Output Data Table. 


T=>0 Data Image Offset 
If the direction is 0 (Client / T= 0): byte offset into the Safety Input Data Table. 
If the direction is 1 (Server /O=T): Always 0. 


5-6.2.1.15 Proxy Device ID 


Proxy Device ID usage for safety: Never used 


5-6.2.1.16 Connection Disable (Attribute 12) 


FRS356 When the Connection Disable attribute in the CCO object is TRUE, the connection 
shall remain disabled through power cycles. When the Connection Disable attribute in the 
CCO object is FALSE, the connection shall remain enabled through power cycles. 


5-6.2.2 Special Safety Related Parameters — (Attribute 13) 


5-6.2.2.1 Ping Interval EPI Multiplier 


This attribute is used as part of the safety Validator function. This parameter is part of the 
Safety Segment Parameters in the Safety Open. Ping_Interval_EPI_Multiplier is the number 
that defines the Ping Count_Interval for the safety connection. 


SRS85 Devices implementing the safety extensions to the CCO object shall perform a range 
check on the Ping Interval EPI Multiplier during a Validate_Configuration request 


Ping Interval EPI Multiplier usage 

Range: [Max_Consumer_Number*Timeout_Multiplier.PI +15] to 1000. 
Default: 

If the direction is 0 (Client/ TO): 100 

If the direction is 1 (Server/O=T): 19 
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Time Coord Msg Min Multiplier 


This attribute is used as part of the Safety Validator function. This parameter is obtained from 
the safety segment parameters in the SafetyOpen. Time_Coord_Msg_Min_Multiplier is the 
minimum number of 128 uS increments it could take for a Time Coordination Message to 
traverse from the consumer to the producer. The default is 0. 


SRS86 Devices implementing the safety extensions to the CCO object shall perform a range 
check on the Time_Coord_Msg_Min_Mulitiplier during a Validate_Configuration request. 


Time Coord Msg Min Multiplier usage 
Range: 0 to 7813, which equates to 0 to 1 sec. 
Default: 2 for non-bridge; 3 or more when bridging is added. 


Network Time Expectation Multiplier 


This attribute is used as part of the Safety Validator function. This parameter is part of the 
safety segment parameters in the SafetyOpen. Network_Time_Expectation_Multiplier is the 
maximum number of 128 uSec increments that a consumer should allow the age of the safety 
data to reach. 


SRS87 Device implementing the safety extensions to the CCO object shall perform a range 
check on the Network_Time_Expectation_Multiplier during a Validate_Configuration request. 


Network Time Expectation Multiplier usage 
RangeO to 45313, which equates to 1 to 5.8 sec. 
Equation: the smaller of 45313 or 


NTEM = [(Timeout_Multiplier.PI + 2) * Data_Production_RPI)J/128 


Timeout Multiplier 


This attribute is used as part of the Safety Validator function. This parameter is part of the 
safety segment parameters in the SafetyOpen. 


SRS88 Device implementing the safety extensions to the CCO object shall perform a range 
check on the Timeout_Multiplier during a Validate_Configuration request. 


Timeout Multiplier usage 


Range BaseFormat: lto4 
Range ExtendedFormat: 1 to 255 
Default 2 


Max Consumer Number 


This attribute defines the maximum number of consumers that are allowed to connect to a 
multi-cast producer (Type 2). Both Multi-cast Consumers and Producers must know this value 
to function properly. This attribute is used as part of the safety Validator function. This 
parameter is part of the Safety Segment Parameters in the Safety Open. 
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SRS89 Device implementing the safety extensions to the CCO object shall perform a range 
check on the Max Consumer Number during a Validate_Configuration request. 


Max Consumer Number usage 


Range: 1 to 15 
Default: 15 
Value: Comes from the Target Applet (i.e. EDS File) 


Target Connection UNID 


This attribute is the UNID of the target safety device for this connection. This parameter is 
part of the Safety Segment Parameters in the Safety Open and is checked by the target device 
to confirm the request didn’t get misrouted. The only way to confirm this value is correct is 
through user testing of the connection. 


Target UNID format on DeviceNet 


Byte 0-5: Safety Network Number 
Byte 6: DeviceNet MacID 
Byte 7-9: Always 0 for DeviceNet 


Safety Configuration CRC (SCCRC) 


The SCCRC serves as a signature for the device configuration and can be used to confirm the 
integrity of the configuration over time. The configuration software shall calculate the SCCRC 
over the configuration data in the exact order it appears in the SafetyOpen message. This same 
calculation is done by target devices and compared to this value. 


SRS90 The SCCRC shall be calculated over the configuration data by the device whenever a 
device configuration is validated (i.e. Validate_Configuration Request to the safety supervisor 
or type 1 safety connection) 


SRS91 The SCCRC shall be saved to NV storage along with the other NV attributes whenever 
a configuration is applied (i.e. apply request to the safety supervisor). 


SRS92 The user shall be instructed in the safety manual to test safety connection 
configurations after they are applied in an originator to confirm the target connection is 
operating as intended. 


Safety Configuration CRC usage 
The target device’s SCCRC. 


Value: Based on the type of safety connection. 
Type 1: SCCRC identifying configuration data in Target Config Data. 
Type 2a: SCCRC identifying the expected target device configuration. 
Type 2b: 0 
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5-6.2.2.8 Configuration Signature (Time Stamp) 
The target device’s SCTS. 


Configuration Time Stamp usage 


Value: Based on the type of safety connection. 

Type |: SCTS identifying configuration data in Target Config Data. 
Type 2a: SCTS identifying the expected target device configuration. 
Type 2b: 0 


5-6.2.2.9 Time Correction EPI 


Defines the EPI for the Time Correction Message used in a multi-cast connection. 


Time Correction EPI usage 


Value: For a multi-cast connection, it is 
Ping Interval EPI Multiplier * Data Production RPI 
Otherwise 0. 


5-6.2.2.10 Time Correction Connection Parameters 


Defines the Connection Parameters used in the Time Correction Message used in a multi-cast 
connection. 


Time Correction Connection Parameter usage 


Value: 0x0000 for a non Multi-cast connection. 
0x2406 for a Multi-cast connection, defined as follows: 
Bits 0-8: Size of the Time Correction Message which is 6 bytes. 
Bit 9: Fixed / Variable 
0 (Fixed) 
Bit 10-11: Priority 
01 (High) 
Bit 12: Reserved 
Always 0 
Bit 13-14: Connection Type 
O1 (Multi-cast) 
Bit 15: Redundant Owner 


Always 0 (Safety doesn’t support Redundancy) 


5-6.2.3 Connection Parameter CRC (CPCRC) - (Attribute 14) 


SRS93 The Connection Parameter CRC attribute shall be calculated by this originator device 
whenever the originator’s configuration is validated (i.e. Validate_Configuration request to the 
safety supervisor). 


SRS94 The CPCRC shall be saved to NV storage along with the other NV attributes whenever 
a configuration is applied (i.e. apply request to the safety supervisor). 


— 5-66 — 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


5-6.2.4 


5-6.2.5 


5-6.2.6 
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The user should be required to test this connection after it is applied to confirm the connection 
configuration. From that point on, the CPCRC serves as a signature for that connection 
configuration and can be used to confirm the integrity of the configuration over time. The 
calculation itself is done over the connection parameters in Safety Open in the exact order they 
appear in the message. This same calculation is done by target devices and compared to this 
value, so the exact order must be followed. 


Configuration Instance — (Attribute 15) 


This attribute provides the linkage to the instance of the object assigned to this connection. 
The attribute may be used when the target’s configuration data cannot be sent via the 
SafetyOpen. A value of 0 (default) for this attribute indicates that no object is assigned. 


Id Allocation 


This Boolean attribute is used to give the user some flexibility in how originators allocate Ids 
on connection establishment. This is particularly important for DeviceNet Safety. The default 
behavior is for the originator to provide Ids for the connections in which it is the producer. If 
the user sets this attribute, the originator will instead ask the Target to provide an Id for these 
produced connections. A user may want to do this when the originator has a large number of 
connections and does not have enough to do the application. This attribute only applies to non- 
multi-cast productions (multi-cast productions must always be allocated by the producer). This 
function should be considered an advanced function and great care should be taken when 
presenting this feature to a user. The user must be advised it should only used in limited 
application scenarios where connection repeatability can be guaranteed. 


Format Type 


The following table defines the Format Type attribute meaning. 


Table 5-6.7 Meaning of the Format Type Attibute 


Format Type a 
Meanin:; 
Value Name 5 
Auto The Originator will determine which format to use at first connection 
establishment. 
Base The Originator will use the existing format at the next connection 
establishment. 
Extended The Originator will use the Extended format at the next connection 


establishment. 


If the Format Type attribute is not set it will default to Auto the originator will determine 
which format to use. If the Format Type attribute is optionally configured to “Base”, the 
originator will only use the “Base” format. If the Format Type attribute is optionally 
configured to “Extended”, the originator will only use the “Extended” format. 


If the Format Type is Base or Extended and a Target responds with a “Invalid Safety 
Connection Format” Error (0x01, 0x803) or “Invalid Safety Connection Size” Error (0x01, 
0x802), the Format Status attribute shall be set to OxFF (Conflict Detected). 
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The Format Type attribute can not be changed while the connection is active. If the format is 
set to Auto, the following logic shown in Figure 5-6.1 be used: 


Figure 5-6.1 Logic for Auto-detecting format type 
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5-6.2.7 


The following table defines the Format Status attribute meaning. 


Format Status 


Table 5-6.8 Meaning of the Format Status Attribute 


Format 
Status Value 
Name 


Meaning Originator 


Meaning Target 


Auto 


The Originator has not yet determined which format to 
use. 


NA 


“Base” 


If Format Type is Auto 
The Originator has determined target requires old 
format 
If Format type is ‘Base, 
The originator will only connect with old format 
If Format type is ‘Extended 
This condition should never occur 


The target is using the “Base” 
format 


“Extended” 


If Format Type is Auto 
The Originator has determined target will accept 
new format 

If Format type is ‘Base, 
The condition should never occur 

If Format type is ‘Extended 
The originator will only connect with the new 
format 


The target is using the 
“Extended” 


‘Conflict 
Detected” 


If Format type is Base or Extended and Segment type 


errors are received, there is setting conflict between Target 


and Originator. This status flags this condition 


The target is receiving 
SafetyOpen requests for a format 
it doesn’t support. 
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Object-Specific Services 
The Connection Configuration Object provides the following Object Specific Services: 


Table 5-6.9 Connection Configuration Object, Object-specific Services 


Service Need in Implementation Service Description of 
Code Class Instance Name Service 
AB hex Conditional! N/A Kick-Timer Kicks Edit Watchdog Timer 
AC trex Optional Conditional” Open Opens connections 
4D trex Optional Conditional” Close Closes connections 
AE tex Optional Conditional” Stop Stops connections 
AF hex Conditional! N/A Change Start Manages session editing 
50 hex Required N/A Get Status Get status for multiple 
connections 

ST hex Conditional! N/A Change Complete Completes session editing 
52 hex Conditional! N/A Audit Changes Audits pending changes 


1, Safety Devices shall not implement these 
configuration through the Safety Supervisor. 

2. FRS357 Safety Devices shall support the Open, Cl 
accepted when the device is unlocked. If the devic 
error. 


‘ices since the software configuration tool will coordinate 


e and Stop services. These services shall only be 
is locked, it shall respond with a “Device state conflict’ 


Common Service Extensions for Safety 


Get Attribute All (Service Code 0x01) 


The added attributes to the end of the Get_Attribute_All response is shown in the two tables 
below. All other parameters of this service are as defined in the standard CCO object in CIP 
Specification Vol.1, Chapter 5. Refer to CCO object in CIP Specification Vol.1, Chapter 5 for 
the position of the two parameter fields in the Get_Attribute_All service. 
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Table 5-6.10 Get_Attributes_All Response Service Data Safety Parameters 


Name Data Type Description 
Safety Parameters STRUCT of 
USINT Pad, set to zero 
USINT Pad, set to zero 
UDINT Configuration CRC (SCCRC 
DATE AND TIME | Configuration Time Stamp (SCTS) 
UDINT Time Correction EPI 
WORD Time Correction Connection Parameters: 
10:octets, Target UNID 
10:octets Pad, set to zero 
UINT Ping Int EPI Mult 
UINT Time Coord Msg Min Mult 
UINT Net Time Exp Mult 
USINT Timeout Multiplier 
USINT Max Consumer Number 
Connection Parameter CRC | UDINT CRC-32 over the connection parameters used in a Safety Open 
Configuration Instance UINT 
ID Allocation Flag BOOL 
Target Connection Serial UINT Safety Validator Instance returned from Target during 


Number 


connection establishment 


Table 5-6.11 Get_Attributes_All Response Service Data Additional Safety Parameters 


Name Data Type Description 
Length USINT Length of additional safety parameters = 4 
Format Type USINT 
Format Status USINT 
Max Fault Number UINT 
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5-6.4.2 Set_Attribute_All (Service Code 0x02) 


The added attributes to the end of the Set_Attribute_All response shall be extended as shown 
in the two tables below. All other parameters of this service are as defined in the standard 
CCO object in CIP Specifications Vol.1, Chapter 5. Refer to CCO object in CIP Specification 
Vol.1, Chapter 5 for the exact position of the two parameter fields in the Set_Attribute_All 
service. 


Table 5-6.12 Set_Attributes_All Request Service Data (Added Attributes) 


Name Data Type Description 
Safety Parameters STRUCT of 
USINT Pad, set to zero 
USINT Pad, set to zero 
UDINT Configuration CRC (SCCRC) (value set = 0, device does this calc) 
DATE AND | Configuration Time Stamp (SCTS) (if applicable, else = 0) 
TIME 
UDINT Time Correction EPI 
WORD Time Correction Connection Parameters. 
10:octets Target UNID 
10:octets Pad, set to zero 
UINT Ping Int EPI Mult 
UINT Time Coord Msg Min Mult 
UINT Net Time Exp Mult 
USINT Timeout Multiplier 
USINT Max Consumer Number 
Configuration UINT 
Instance 
ID Allocation Flag BOOL 
Table 5-6.13 Set_Attributes_All Request Service Data Additional Parameters 
Name Data Type Description 
Length USINT Length of additional safety parameters = 3 
Format Type USINT 
Max Fault Number UINT 


5-6.4.3 Restore (Service Code 0x15) 


Safety devices shall not implement the Restore service at either class or instance level since the 
configuration tool will coordinate configuration through the Safety Supervisor. 


5-6.5 Object Behavior 
The Connection Configuration object behavior for Safety Devices shall be controlled by the 


Safety Supervisor and follow the behavior shown in Table 5-6.14, Figure 5-6.2, and Figure 5- 
6.3. 


State mapping between Safety Supervisor and Connection Configuration objects 
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Table 5-6.14 State Mapping between Safety Supervisor and the CCO objects 


Safety Supervisor Connection Configuration 

Self-Testing Edits Not allowed 
Self-Test Exception Edits Not allowed 
Idle Edits Not allowed 
Configuring Edits allowed 

Executing Edits Not allowed 
Abort Edits Not allowed 
Critical Fault Edits Not allowed 


Figure 5-6.2 Connection Configuration Object State Diagram 
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The Data flow for the Connection Configuration object while in the Configure State is shown 
in Figure 5-6.3 


Figure 5-6.3 Connection Configuration Object Data Flow 
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5-7 Safety Discrete Input Point (SDIP) 
Class Code: 3Dhex 
The Safety Discrete Input Point Object models discrete safety inputs in a product. This object 
can be used in any device that contains discrete safety inputs. Note that the term “input” is 
defined from the network’s point of view. An input will produce data on the network. 
The Safety Discrete Input Point interface is to real input points such as a switch or screw 
terminal. The input is sampled and evaluated, the evaluated result is stored in this object’s 
Safety Input Logical Value attribute. 
5-7.1 Revision History 
Revision 
OL Initial definition at First Release of the Object 
5-7.2 Class Attributes 
Table 5-7.1 Safety Discrete Input Point Class Attributes 
Attr | Need in Access | NV Name Data Description of Attribute Semantics of Value 
ID Implem Rule Type 
1 See the CIP Common Specification, Vol. 1, Chapter 4-9.1 for a description of these class attributes. 
thru 
7 
8 Required Set ! NV_ | Latch Input UINT Any Safety Input or Test 0 to 65565, in milli- 
Error Time * Output error will be latched seconds. The default 
for this minimum time. If value is 1000. 
the error is no longer present 
after this time the error 
condition may be reset by 
the module. 
1. Applications including this attribute may restrict its access to Get 
2. Itis acceptable to support a subset of the complete range of values. 
5-7.3 Instance Attributes 
Table 5-7.2 Safety Discrete Input Point Instance Attributes 
Attr Need in Access | NV Name Data Description of Attribute Semantics of Value 
ID Implem Rule Type 
1 Optional Get Number of USINT | Number Supported in this 
Attributes product. 
2 Optional Get Attribute Array List of Attributes 
List of supported in this product. 
USINT 
3 Optional Get Input Port BOOL Input point value at the 0= Off 
Value terminal prior to the on/off | j= On 
delay evaluation. Ane 
This is not safety data, 
there is no safety state. 
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Attr Need in Access | NV Name Data Description of Attribute Semantics of Value 
ID Implem Rule Type 
4 Required Get Safety Status | BOOL Input point status. 0= Alarm 
1=OK 
This Value is Safety 
Data with a Safety State 
of 0. 
bs Optional Set | NV_ | Off_On UINT Filter time for off to on The default is 0. 
Delay 2 transition 
0-65,535 milli-seconds * 
6 Optional Set ' NV_ | On_Off UINT Filter time for on to off The default is 0. 
Delay ” transition 
0-65,535 milli-seconds * 
7 | Required | Get Safety Input | BOOL | Input point value after 0= Off 
Logical safety and on/off delay 1=On 
Value evaluation. : 
This Value is Safety 
Data with a Safety State 
of 0. 
8 Optional Set NV_ | Input USINT | Input Point Mode. The default is 0. 
Channel 0 = not used 
Mode ~ : ‘ 
1 = input, with test 
pulse from test out 
2 = input, no 
dependency to test out. 
(Used as, 
semiconductor input). 
3 = input, no 
dependency to test out. 
(Used as standard 
input). 

9 Optional Set | NV_ | Test Source | USINT | A pointer to the test output | The instance number of 
that is used with this input | the Discrete Output 
when the Input Channel Point Object instance 
Mode is set to 1. that is used as a test 

output for this input. 

10 | Optional Get Standard BOOL | Input point value at the O= Off 

Input Value terminal with the on/off 1=On 
delay evaluation, but prior aa Sis 
to safety input evaluation, | THis is not safety data, 
there is no safety state. 


1. Applications including this attribute may restrict its access to Get. 


recorded in the Logical Value Attribute. 


. When this attribute is supported it is acceptable to support a subset of the complete range of values. 
The input must be on for the filter time specified by the ON_OFF Delay attribute before the OFF state is 


If the “Test Source” attribute of one or more Discrete Safety Input Point object instances is 
equal to an instance of the Discrete Output Point, and the “Input Channel Mode” attribute is 
equal to 1, then the “Test Output Mode” attribute (refer to Section 5-12-1, Attribute 13) of that 
Discrete Output Point instance must be set equal to 2= Test Output. 


If the “Test Source” attribute of more than one Discrete Safety Input Point object instances is 
equal to an instance number of Discrete Output Point object, the “Input Channel Mode” 
attributes of those Safety Input Point instances must be identical. 
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Common Services 
The Safety Discrete Input Point Object provides the following services. 


Table 5-7.3 Safety Discrete Input Point Common Services 


Service | Need in Implementation Service Name Description of Service 
Code Class Instance 
OE nex Conditional | Required Get_Attribute_Single Returns the contents of the specified 
attribute. 
10nex Optional Optional Set_Attribute_Single Modifies an attribute value. 


Object-specific Services 


The Safety Discrete Input Point Object requires no Object-specific services. 
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5-7.6 Behavior 

5-7.6.1 Type of Safety Inputs 
The following table defines the types of safety inputs that are supported by the Safety Discrete 
Input Point Object. The effects on the Safety Input Logical Value, Status, and Test Source 
attributes are also shown. The SDIP object is designed for De-energized to trip behavior. 
Because of this design the Safety State of the Safety Data attributes is 0 or de-energized. 
Table 5-7.4 Supported Safety Input Types 
Input Channel Mode Safety Input Type 

0 = not used 


1 = input, with test pulse from test out 
2 = input, no dependency to test out. 
(Used as, semiconductor input). 

3 = input, no dependency to test out. 
(Used as standard input). 


0 Type | Not Used 
Input Port Value | Set to 0 
Standard Input Value | Set to 0 
Safety Input Logical Value | Set to 0 
Status | Set to0 
1 Type | Single Channel Input (w/test pulses from test out) 
Input Port Value | Set to Input Terminal value 
Standard Input Value | Set to Input Terminal value with the on/off delay 
evaluation 
Safety Input Logical Value | Set to Standard Input Value if no errors. 
Set to 0 if external or internal test fails. 
Status | Set to Input Status 
2 Type | Single Channel Input (no dependency to test out. 
{Used in application as a semiconductor input}) 
Input Port Value | Set to Input Terminal value 
Standard Input Value | Set to Input Terminal value with the on/off delay 
evaluation 
Safety Input Logical Value | Set to Standard Input Value if no errors. 
Set to 0 if internal test fails. 
Status | Set to Input Status 
3 Type | Single Channel Input (no dependency to test out. 
{Used in application as a standard input}) 
Input Port Value | Set to Input Terminal value 


Standard Input Value 


Set to Input Terminal value with the on/off delay 
evaluation 


Safety Input Logical Value 


Set to Standard Input Value if no errors. 
Set to 0 if optional internal test fails. 


Status 


Set to Input Status 
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5-7.6.2 Safety Discrete Input Evaluation Behavior 
The following diagram depicts the flow of the Safety Discrete Input Evaluation behavior. 


Figure 5-7.1 Safety Discrete Input Evaluation Flow 
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The details of the on/off delay filter algorithm used are product specific. The Input Port Value 
attribute shall be set to 0 when the Input Channel Mode attribute is set to Not Used. 


The details of the Test Evaluation algorithms used are product specific. 


The following diagram defines the behavior of the Input Evaluation portion of the diagram 
above. 


Figure 5-7.2 Input Evaluation Behavior 
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5-8 Safety Discrete Input Group (SDIG) 
Class Code: 3Ehex 


The Safety Discrete Input Group Object binds a group of discrete safety input points in a 
module. All points bound to the group share all attributes contained in the group. If an 
attribute is shared (points have the same attributes and the same attribute values) across more 
than one Safety Discrete Input Point, then that attribute can be contained in a Safety Discrete 
Input Group. A Discrete Input Point can be bound to more than one Discrete Input Group. 


You must establish the list of discrete safety input points bound to the group at power-up, as 
the binding list is static and is a Get-only attribute of the group. 
Use the Safety Discrete Input Group Object: 


e when a single attribute is shared among many safety input points. 


¢ to more efficiently access data (services that affect all members of a group can be supported 
by the Safety Discrete Input Group). 


Figure 5-8.1 Discrete Input Group 
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5-8.1 Revision History 
Revision 
01 Initial definition at First Release of the Object 
5-8.2 Class Attributes 


Table 5-8.1 Safety Discrete Input Group Class Attributes 


Attr Need in Access | NV Name Data Description of Attribute Semantics of 
ID Tmplem Rule Type Value 


1 See the CIP Common Specification, Vol. 1, Chapter 4-9.1 for a description of the optional, reserved class 
thru attributes. 
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5-8.3 Instance Attributes (Common) 


Table 5-8.2 Safety Discrete Input Group Instance Attributes 


Attr Need in Access | NV Name Data Description of Attribute Semantics of 
ID Implem Rule Type Value 
1 Optional Get Number of USINT | Number Supported in this 
Attributes product. 
2 Optional Get Attribute Array List of Attributes supported 
List of in this product. 
USINT 
3 Optional Get Number of USINT | Number of points bound to 
Bound this group 
Instances 
4 Optional Get Binding Array List of all points bound to Class SDIP 
of this group Instance #X 
UINT 5 
Instance ID Class SDIP 
Instance #Y... 
5 Required | Get Safety Status | BOOL | Status for all discrete input 0= Alarm 
points in the group 1=OK 
This Value is 
Safety Data with a 
Safety State of 0. 
6 Optional Set NV _ | Off_On UINT Filter time for off to on The default is 0. 
Delay y transition 
0-65,535 milli-seconds 
E Optional Set NV_ | On_Off UINT Filter time for on to off The default is 0. 
Delay ! transition 
0-65,535 milli-seconds 


1, When this attribute is supported it is acceptable to support a subset of the complete range of values. 


5-8.4 Common Services 
The Safety Discrete Input Group Object provides the following services. 


Table 5-8.3 Safety Discrete Input Group Common Services 


Service Need in Implementation Service Name Description of Service 
Code Class Instance 
OE nex Conditional Required Get_Attribute_Single Returns the contents of the 
specified attribute. 
10hex Optional Optional Set_Attribute_Single Modifies an attribute value. 
5-8.5 Object-specific Services 


The Safety Discrete Input Group Object requires no Object-specific services. 


5-8.6 Behavior 


The Status behavior is a simple AND’ ing of the Status of the bound Safety Discrete Input 
Points. 
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5-9 Safety Discrete Output Point (SDOP) 
Class Code: 3Bhex 


The Safety Discrete Output Point Object models discrete safety outputs in a product. This 
object can be used in any device that contains discrete safety outputs. Note that the term 
“output” is defined from the network’s point of view. An output will consume data from the 
network. 


The Safety Discrete Input Point interface is to real safety output points such as a Safety 
Semiconductor Outputs or a Safety Relays. The output is read from the object’s Safety Output 
Value attribute and applied to the safety output. 


5-9.1 Revision History 
Revision 
Ol Initial definition at First Release of the Object 
5-9.2 Class Attributes 
Table 5-9.1 Safety Discrete Output Point Class Attributes 
Attr. Need in Access NV Name Data Description of Attribute Semantics 
ID Implem Rule Type of Value 
1 thru | See the CIP Common Specification, Vol. 1, Chapter 4-9.1 for a description of the optional, reserved class 
7 attributes. 
8 Required | Set! NV | Latch Output UINT | Any Safety Output error will | 0 to 65565, 
Error Time * be latched for this minimum | in milli- 
time. If the error is no seconds. 
longer present after this time | The default 
the error condition may be value is 
reset by the module. 1000. 


1. Applications including this attribute may restrict its access to Get. 


2. When this attribute is supported it is acceptable to support a subset of the complete range of values. 


5-9.3 Instance Attributes (Common) 


Table 5-9.2 Safety Discrete Output Point Instance Attributes 


Att. Need in Access | NV Name Data Description of Attribute Semantics of Value 
ID Implem Rule Type 
1 Optional Get Number of USINT | Number Supported in this 
Attributes product. 
2 Optional Get Attribute List Array List of Attributes 
of supported in this product. 
USINT 
3 Required Get | Safety Output BOOL | Output point value. This O= Off 
Value is the value that the 1=On 
output is commanded to : 
bein: This Value is Safety 
Data with a Safety 
State of 0. 
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Att. Need in Access | NV Name Data Description of Attribute Semantics of Value 
ID Implem Rule Type 
4 Required Get Output Monitor | BOOL | Output point value, For O= Off 
Value semi-conductor outputs, 1=On 
the value at the terminal _. ; 
screw. For safety relay This is not safety data, 
outputs it is the relay there is no safety state. 
state red back from the 
internal auxiliary 
contacts. 
5 Required Get Safety Status BOOL | Safety output point status | 0= alarm 
1=OK 
This Value is Safety 
Data with a Safety 
State of 0. 
6 Optional Set? NV Output Channel | USINT O= Not Used 
Mode * 1= Used, 
No Test Pulses 
2= Used, 
Test Pulses 
Default = Not Used 


1. 


Settable only by Safety I/O Connections, not settable by explicit messaging. 


2. Applications including this attribute may restrict its access to Get. 
3. When this attribute is supported it is acceptable to support a subset of the complete range of values. 
5-9.4 Common Services 
The Safety Discrete Output Point Object provides the following services. 
Table 5-9.3 Safety Discrete Output Point Common Services 
Service | Need in Implementation Service Name Description of Service 
Code Class Instance 
OE nex Conditional | Required Get_Attribute_Single Returns the contents of the specified attribute. 
10hex Optional Optional Set_Attribute_Single Modifies an attribute value. 
5-95 Object-specific Services 
The Safety Discrete Output Point Object requires no Object-specific services. 
5-9.6 Behavior 


Figure 5-9.1 depicts the flow of the Safety Discrete Output Evaluation behavior. The SDOP 
object is designed for De-energized to trip behavior. Because of this the Safety State of the 
Safety Data attributes is 0 or de-energized. 
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Figure 5-9.1 Safety Discrete Output Evaluation Data Flow 
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The details of the Test Evaluation algorithms used are product specific. 
The Output should be de-energized any time that the Status indicates Alarm. 


Figure 5-9.2 defines the behavior of the Status Evaluation portion of the Discrete Safety Output 
Evaluation behavior. 


Figure 5-9.2 Safety Discrete Output Status Evaluation Data Flow 
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5-10 Safety Discrete Output Group (SDOG) 
Class Code: 3Chex 


The Safety Discrete Output Group Object binds a group of discrete safety output points in a 
module. All points bound to the group share all attributes contained in the group. If an 
attribute is shared (points have the same attributes and the same attribute values) across more 
than one Safety Discrete Output Point, then that attribute can be contained in a Safety Discrete 
Output Group. A Safety Discrete Output Point can be bound to more than one Safety Discrete 
Output Group. 


You must establish the list of discrete safety output points bound to the group at power-up, as 
the binding list is static and is a Get-only attribute of the group. 
Use the Safety Discrete Output Group Object: 


e when a single attribute is shared among many safety output points. 
e to more efficiently access data (services that affect all members of a group can be supported 
by the Safety Discrete Output Group). 


Figure 5-10.1 Safety Discrete Output Group 


Discrete Safety | 
Output Group) | 


Discrete Safety Discrete Safety ecco Discrete Safety 
Output Point Output Point Output Point 
5-10.1 Revision History 
Revision 
Ol Initial definition at First Release of the Object 
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5-10.2 


5-10.3 


5-10.4 


Safety Discrete Output Group Object, Class Code: 3Cyex 


Class Attributes 


Table 5-10.1 Safety Discrete Output Group Class Attributes 


Attr Need in Access | NV Name Data Description of Semantics of 
ID Implem Rule Type Attribute Value 

1 thru | See the CIP Common Specification, Vol. 1, Chapter 4-9.1 for a description of the optional, reserved class 

7 attributes. 


Instance Attributes (Common) 


Table 5-10.2 Safety Discrete Output Group Instance Attributes 


Attr Need in Access | NV Name Data Description of Semantics of 
ID Implem Rule Type Attribute Value 
1 Optional Get Number of USINT | Number Supported in 
Attributes this product. 
2 Optional Get Attribute Array List of Attributes 
List of supported in this 
USINT. | product. 
3 Optional Get Number of USINT | Number of points 
Bound bound to this group 
Instances 
4 Optional Get Binding Array | List of all points Class SDOP 
of bound to this group Instance #X 
UINT e 
Instance ID Class SDOP 
Instance #Y... 
5 Required Get Safety Status | BOOL | Safety output status O= alarm 
for all discrete safety 1=OK 
outputs in the group. ‘ ‘ 
This Value is 
Safety Data with a 
Safety State of 0. 
7 Optional Set NV Output USINT | Output Channel Mode | 0= Not Used 
Channel for all discrete safety 1= Used. 
Mode ! outputs in the group. 
No Test Pulses 
2= Used, 
Test Pulses 
1. When this attribute is supported it is acceptable to support a subset of the complete range of values. 
Common Services 
The Safety Discrete Input Point Object provides the following services. 


Table 5-10.3 Safety Discrete Output Group Common Services 


Service | Need in Implementation Service Name Description of Service 
Code Class Instance 
OE nex Conditional | Required Get_Attribute_Single Returns the contents of the specified 
attribute. 
10hex Optional Optional Set_Attribute_Single Modifies an attribute value. 
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5-10.5 Object-specific Services 


The Safety Discrete Output Group Object requires no Object-specific services. 


5-10.6 Behavior 


The Status behavior is a simple AND’ ing of the Status of the bound Safety Discrete Output 
Points. 
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5-11 Safety Dual Channel Output Object (SDCO) 


Class Code: 3Fhex 


The Safety Dual Channel Output Object models a pair of safety output channels as dual 
channel safety outputs in a product. This object must be used in conjunction with two instances 
of a Safety Discrete Output Point Object. This object can be used in any device that contains 
discrete safety outputs. Note that the term “output” is defined from the network’s point of 
view. An output will consume data on the network. 


5-11.1 Revision History 


Revision 


OL Initial definition at First Release of the Object 


5-11.2 Class Attributes 


Table 5-11.1 Safety Dual Channel Output Class Attributes 


Attr Need in Access 
ID Implem Rule 


N Name 
hie 


Data Description of 
Type Attribute 


Semantics of Value 


1 See the CIP Common Specification, Vol. 1, Chapter 4-9.1 for a description of the optional, reserved class 


thru attributes. 
if 


5-113 Instance Attributes (Common) 


Table 5-11.2 Safety Dual Channel Output Instance Attributes 


Attr Need in Access | N Name Data Description of Semantics of Value 
ID Implem Rule v Type Attribute 
1 Optional Get Number of USINT | Number Supported in 
Attributes this product. 


2 | Optional | Get 


Attribute List 


Array List of Attributes 
of supported in this 
USINT | product. 


3 Required Set! N Dual Channel | USINT | Mode of the dual Default = 1. 
Vv Mode channel safety output | g single channel 
air. 
e 1 = dual channel 
4 Optional Set? N | Member One | USINT | A pointer to the first The instance number of 
Vv member of the dual the SDOP Object that is 
channel safety output | used as member one of 
pair. the dual channel safety 
output pair. 
5 Optional Set? N Member Two | USINT | A pointer to the The instance number of 


second member of 
the dual channel 
safety output pair. 


the SDOP Object that is 
used as member one of 
the dual channel safety 

output pair. 


1. Applications including this attribute may restrict its access to Get. 


2. It is optional that these parameters be made publicly visible. However, all Validator instances shall have internal 
parameters which represent these variables. 
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5-11.4 Common Services 


The Safety Dual Channel Output Object provides the following services. 


Table 5-11.3 Safety Dual Channel Output Common Services 


Service Need in Implementation Service Name Description of Service 
Code Class Instance 
OE nex Conditional Required Get_Attribute_Single | Returns the contents of the specified 
attribute. 
10nex Optional Optional Set_Attribute_Single Modifies an attribute value. 


5-11.5 Object-specific Services 


The Safety Dual Channel Output Point Object requires no Object-specific services. 


5-11.6 Dual Channel Evaluation Behavior 


The Safety Dual Channel Output has no behavior above the Safety Discrete Output Point 
(SDIP) object instances when the Output Channel Mode is set to Single. 


Figure 5-11.1 depicts the flow of the Dual Channel Evaluation behavior for Output Channel 
Mode set to Dual. 


Figure 5-11.1 Dual Channel Evaluation Data Flow 
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The behavior is described in terms of: 


1. Single Channel Evaluation of Channels A and B 
2. Dual Channel Evaluation 


The Single Channel Evaluation is described by the Safety Discrete Output Point (SDOP) object 


for all outputs used in the Safety Dual Channel Output (SDCO). 
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From a behavioral perspective, the Dual Channel Evaluation portion of the SDCO takes the 
following inputs: 


A. The Status from Channel A Single Channel Evaluation (Ok or Alarm) 
B. The Status from Channel B Single Channel Evaluation (Ok or Alarm) 
C. The Safety Out Values for Channel A (0 or 1) 
D. The Safety Out Values for Channel B (0 or 1) 


From a behavioral perspective, the Dual Channel Evaluation produces the following outputs: 


e The Status attributes of the Channel A and Channel B Safety Discrete Output Point 
instances. 


Table 5-11.4 defines the Dual Channel Evaluation behavior for Output Channel Mode set to 
Dual. 


Table 5-11.4 Dual Channel Evaluation Behavior 


From Single Channel Safety Output Values Results applied to Channel A and 
Evaluation Channel B “Status” attributes 
Status A Status B Channel A Channel B “Status” A & B 
Ok Ok 0 0 OK 
Ok Ok 0 1 Alarm 
Ok Ok 1 0 Alarm 
Ok Ok 1 1 OK 
Alarm x x x Alarm 
x Alarm x x Alarm 


x = don’t care 


The dual channel output status bits may only transition from Alarm to Ok when both outputs 
are in the inactive state at the same time. 
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5-12 


5-12.1 


5-12.2 


Discrete Output Point Object, Class Code: 09pex 


Discrete Output Point Object 
Class Code: 09hex 


This section defines the extensions to the Discrete Output Point (DOP) Object, Class 0x09 for 
CIP Safety. (Also see Volume 1, Chapter 5 for the complete object definition.) 


Test Output Mode for Safety Attribute 
The Test Output Mode For Safety attribute is added to the DOP object. 


Table 5-12.1 Test Output Attribute Detail 


Att. Need in |Access| NV Name Data Description of Semantics of 
ID Implem Rule Type Attribute Value 
13 Optionall Set NV _ |Test Output Mode When |USINT |Mode of this Test The default is 0. 
this attribute is supported output Point See Semantics 


it is acceptable to support 
a subset of the complete 
range of values. 


1. When this attribute is supported it is acceptable to support a subset of the complete range of values. 


Test Output Mode Semantic 


The Test Output Mode attribute may be used on modules that have output points that are 
configurable as either standard Discrete Output Points or as Test Output Points to be used 
within a safety system. The following table defines the semantic of the test output mode. 


Table 5-12.2 Test Output Mode Values 


Test Output A 
Point Mode Test Output Point Type 

0 Not Used, The output is deactivated. Default Value 

1 The output point is configured as a standard output. The Output is controlled by the Value attribute. 

2 The output point is configured as a test output. This test output is used in conjunction with the 
Safety Discrete Input Point object instance(s) whose Test Source attribute (refer to Section 5-7.3, 
Attribute 9) is equal to this Output Points instance number. The Output is activated with test pulses 
and cannot be controlled externally. 

s} The output point is configured as a power supply output. The output is permanently activated or set 
to high. 

4 The output point is configured as a Muting Lamp output. The status of the Muting Lamp Output is 
available in the Status attribute of this DOP instance. The Output is controlled by the Value 
attribute. 

All other [Reserved by CIP 
values 
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5-13 TCP/IP Object 


TCP/IP Object, Class Code: F5yex 


Class Code: F5 Hex 
This section defines the changes and additions required of the TCP/IP object to support CIP 


safety. 


5-13.1 TCP/IP Object Instance Attribute Changes 


An instance attribute shall be added to allow the Safety Network Number (SNN) to be read. 


The definition for tl 


is attribute is as follows: 


Table 5-13.1 Safety Network Number Attribute Detail 


Attr Need in Access Name Data Description of Semantics of Value 
ID Implem Rule Type Attribute 
7 Required Get Safety Network 6 octets | System-wide unique Attribute shall 


Number 


number for the 
subnet this device 
resides on. 


contain the SNN 
portion of the 
TUNID in the Safety 
Supervisor. See 
Chapter 2-3.1.1 fora 
complete definition 
of the SNN. 


SRS209 Devices implementing EtherNet/IP Safety shall support attribute 7 of the TCP/IP 


object. 
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5-14 


5-14.1 


5-14.2 


5-14.3 


Safety Analog Input Point Object, Class Code: 49 pcx 


Safety Analog Input Point Object 
Class Code: 49 hex 


The Safety Analog Input Point (SAIP) Object models Safety Analog Input channels in a 
product. It can be used in applications as simple as a single analog point and as complex as an 
analog I/O control module. Note that the term “input” is defined from the network’s point of 
view. An input produces data onto the network. 


The Safety Analog Input Point interfaces to analog input devices such as a temperature sensor 
or pressure transducer. The input is sampled and processed through filtering and conditioning 
algorithms and the resulting data is produced onto the network. When signal integrity is 
verified by vendor specific algorithms, the result is saved in this object’s Safety Analog Input 
Value attribute. The main feature of the Safety Analog Input Point is that underlying device 
implements internal diagnostics sufficient to ensure that the Safety Analog Input Value meets 
Safety Integrity Level (SIL) requirements (SIL level achieved depends on the implementation). 
Whenever a fault is detected that makes the signal integrity unreliable, a fault state is declared 
and a safe value is reported to the control system. 


Revision History 


This is the initial release of this object. The table below represents the revision history: 


Table 5-14.1 Safety Analog Input Point Object Revision History 


Revision Reason for object definition update 
ol Initial Definition at First Release of Specification 


Class Attributes 


Table 5-14.2 Safety Analog Input Point Object Class Attributes 


Attr Need in Access N Name Data Description of Semantics of Value 
ID Implem Rule v Type Attribute 


1 thru | See the CIP Common Specification, Vol. 1, and Chapter 4-9.1 for a description of the optional, reserved 
Es class attributes. 


Instance Attributes 


Table 5-14.3 Safety Analog Input Point Object Instance Attributes 


AttrID| Needin Access | NV Attribute Data Description of Semantics of Values 


Implem Rule Name Type Attribute 
1 Optional Set! NV | Data Type USINT | Determines the data | C3 = INT (default) 
type of Safety See Appendix C-6.1 See 


Analog Input Value | Semantics section. 
and all related 
attributes as 
specified in this 
table. 
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AttrID| Need in Access | NV Attribute Data Description of Semantics of Values 
Implem Rule Name Type Attribute 
2 [Required |Get V |Safety Analog [INT or | Analog Input value | See Semantics section. 
Input Value based after conditioning, This is Safety Data with 
on Dara | filtering and SIL safe Value defined by 
Type _ integrity testing. _| safe State attributes. 
3 Required Set! NV | Input Range USINT | Input range the See Semantics section. 
point is operating in 
4 | Required Set NV | Input Channel | USINT | Input Point Mode | 0 = Not used (default) 
Mode 1 = Safety, with SIL 
integrity testing 
2 = Standard, with no 
SIL integrity testing 
5 Required Get V_| Input Point BOOL | Status of the 0= Alarm 
Status Analog Input Point} 1 =OK 
This is Safe Data with 
Safety State of 0. 
6 — | Required Get V_ | Point Fault USINT | Determines the fault} | = Operating Normally 
Reason type that exists on | See Semantics section. 
the input 
it Optional Set! NV | Real Time UINT | Millisecond interval | See Semantics section. 
Sample Period at which input data 
is sampled. 
8 Optional Set! NV | Input Error UINT | Minimum time a 0 - 65535 ms, 
Latch Time Safety Input error | default = 1000 
will be latched for. a ; 
See Semantics section. 
9 Optional Set NV | Full Scale INT or | The value of Full The value of Safety 
based Scale for the sensor | Analog Input Value 
on Data corresponding to the Full 
Type Scale calibrated 
measurement of the 
sensor. Default = 
Maximum value for the 
Data Type. 
10 | Optional Set! NV | Safe State USINT | Defines behavior 0 = Use Safe State Value, 
Behavior for value reporting | default. 
when faulted. See Semantics section. 
11 | Optional Set! NV | Safe State INT or | Safe State Analog | 0 = default. 
Value based —_| Input value. 
on Data 
Type 
12 | Optional Set NV | Low Signal INT or | Determines the data | Default = Min value for 
based | low signal value for | Data Type. See 
on Data | scaling the raw Semantics section. 
Type analog input. 
13 | Optional Set NV | High Signal INT or | Determines the data | Default = Max value for 
based | high signal value Data Type. See 
on Data | for scaling the raw _ | Semantics section. 
Type analog input. 
14 | Optional Set NV | Low INT or | Determines the data | Default = Input Range 
Engineering | based | low engineering _| Min. See Semantics 
Value on Daita | value for scaling the } section. 
Type raw analog input. 
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Data 


AttrID| Needin Access | NV Attribute Description of Semantics of Values 
Implem Rule Name Type Attribute 
15 | Optional Set NV | High INT or | Determines the data | Default = Input Range 
Engineering | based _| high engineering Max. See Semantics 
Value on Data | value for scaling the | section. 
Type raw analog input. 
16 Optional Get V_ | Alarm and BYTE | Indicates the level OxOF = No alarms, See 
Warning Status of alarm or warning | Semantics section. 
that has occurred, 
17 | Optional Set NV ] Alarm Enable |BOOL | Enable Alarm 0 = Disable, default 
Status Checking 1 = Enable 
18 | Optional Set NV | Alarm Trip INT or | Specifies the Value | See Semantics section, 
Point High based | above which an Default = Max value for 
on Data | Alarm Condition Data Type 
Type will occur. 
19 Optional Set NV | Alarm Trip INT or | Specifies the Value | See Semantics section, 
Point Low based | below which an Default = Min value for 
on Data | Alarm Condition —_| Data Type 
Type will occur. 
20 | Optional Set NV | Alarm INT or | Specifies the 0 = default 
Hysteresis based |amount by which __| See Semantics section. 
on Data | the Safety Analog 
Type Input Value must 
recover to clear the 
Alarm condition. 
21 | Optional Set NV | Alarm Settling | UINT | Determines the time | Time in milliseconds 
Time that the Value must | 0 = default 
exceed the Alarm | See Semantics section. 
Trip Point before an 
Alarm Condition 
will occur. 
22 Optional Set NV | Warning BOOL | Enable Warning 0 = Disable, default 
Enable Status Checking 1 = Enable 
23 | Optional Set NV | Warning Trip }INT or | Specifies the Value | See Semantics section, 
Point High based | above which a Default = Max value for 
on Data | Warning Condition | Data Type 
Type will occur. 
24 | Optional Set NV | Warning Trip | INT or | Specifies the Value | See Semantics section, 
Point Low based | below which a Default = Min value for 
on Data | Warning Condition | Data Type 
Type will occur. 
25 — | Optional Set NV | Warning INT or | Specifies the 0 = default 
Hysteresis based |amount by which | See Semantics section. 
on Data | the Safety Analog 
Type | Input Value must 
recover to clear the 
Warning condition 
26 | Optional Set NV | Warning UINT | Determines the time | Time in milliseconds 
Settling Time that the Value must | 0 = default 
exceed the Warning | See Semantics section. 
Trip Point before a 
Warning Condition 
will occur. 
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Attr ID 


Safety Analog Input Point Object, Class Code: 49 pcx 


Data 


Need in Access | NV Attribute Description of Semantics of Values 
Implem Rule Name Type Attribute 
27 Optional Get NV | Over Range INT or | Shows the highest | The value above which 
Value based | valid Analog Input | the Over Range condition 
on Data | value after is declared. See 
Type conditioning and Semantics 
filtering. 
28 Optional Get NV | Under Range |INTor | Shows the lowest The value below which 
Value based | valid Analog Input | the Under Range 
on Data | value after condition is declared. See 
Type | conditioning and Semantics 
filtering. 
29 | Optional Get NV | Offset-A Data | USINT | Determines the data | C3 = INT (default) 
Type type of Offset-A | See Appendix C-6.1 
See Semantics section . 
30 | Optional Set NV | Offset-A INT or | Amount added 0 = default 
based | before Gain to . . 
ari derive Safety See Semantics section. 
Offset- | Analog Input Value 
A Data 
Type 
31 | Optional Get NV | Gain Data USINT | Determines the data | C3 = INT (default) 
Type type of Gain See Appendix C-6.1 
See Semantics section . 
32 | Optional Set NV | Gain REAL | Amount scaled to | 1.0 = default 
or derive Safety 5 ‘ 
based | Analog Input Value | See Semantics section. 
on 
Offset- 
A Data 
Type 
33 | Optional Get NV | Unity Gain REAL | Specifies the value | 1.0 = default 
Reference or of the Gain attribute Used to normalize the 
based | equivalent to a gain | Gaiy attribute. 
on Gain | of 1.0 
Data 
Type 
34 Optional Set NV | Offset-B INT or | Amount added to 0 = default 
based | derive Safety F : 
on Data | Analog Input Value | See Semantics section. 
Type 
35 | Optional Set NV | Produce INT or | Amount by which | 0 = default 
Trigger Delta | based | Safety Analog Input | See Semantics section. 
on Data | Value must change 
Type to cause a change of 
state production. 
36-79 | Reserved 
80-96 | Reserved for 
Subclass use 
97,98 | Reserved 
99 |Optional — |Get NV | Subclass UINT [Identifies a subset [0 = No subclass (default) 


of application 
specific attributes, 
services, and 
behaviors. 


1 — 65535 Reserved 


1. Attribute may be implemented as Get only. 
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Important: Attributes are only settable when the Safety Supervisor is in the Configuring state. 


Semantics 


This section defines the semantics of the Safety Analog Input Point object attributes. 


Data Type, Attribute 1 


The Data Type attribute determines the data type to be used by the Safety Analog Input Value, 
High and Low Signal, High and Low Engineering Value, Full Scale, Safe State Value, Over 
Range, Under Range, and Alarm and Warning Trip Points, Hysteresis, Offset-B and Produce 
Trigger Delta attributes. The implementation may support only those Data Type values needed 
for its application. If Data Type is not supported, then the data type of the Safety Analog Input 
Value and all other related attributes shown above, defaults to INT. 


The Data Type attribute uses the following enumerated numeric types defined in Volume 1, 
Appendix C-6.1. 


SINT (C2), USINT (C6) 
© INT (C3), UINT (C7) 

© DINT (C4), UDINT (C8) 
¢ LINT (C5), ULINT (C9) 
¢ REAL (CA) LREAL (CB) 


Safety Analog Input Value, Attribute 2 


The Safety Analog Input Value attribute represents the analog input signal after it has been 
processed through the conditioning, filtering and testing algorithms. This value is reported to 
the safety controller. In general, the SIL integrity testing covers the signal input circuit 
reliability and value reliability. The methods used to meet SIL integrity testing are vendor 
specific. 


The Safety Analog Input Value is derived as follows: 
Value = GainN * (Raw Sensor Value + Offset-A) + Offset-B 
Where GainN = Gain / Unity Gain Reference 


The Offset-A and Offset-B values are typically modified by the Zero_Adjust services and the 
Gain is modified by Gain_Adjust service. 


When the point input is paired with a second Safety Analog Input Point (see Safety Dual 
Channel Analog Input, CIP Safety Specification, Vol 5, section S-TBD), the Safety Analog 
Input Value is the “consensus” value of the dual input pair. The details of developing the 
“consensus” value are vendor specific. 
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Input Range, Attribute 3 


The Input Range attribute determines the set of analog values within which the inputs may 
operate. The value of the Input Range affects the default and legal values that other attributes 
may have. 


Input Range is required if the point may be switched to operate within different ranges, which 
changes the behavior of the point. For example, if the point is configured to operate from OV to 
SV or from 4mA to 20mA, the variability of ranges will likely change the expected behavior of 
the Value attribute and perhaps change vendor specific attributes. The implementation may 
support only those range values needed for its application. 


Table 5-14.4 Input Range Values 


Range Value Range and Units 
0 -10 to 10 volts 
1 0 to 5 volts 
2 0 to 10 volts 
ej 4 to 20 milliamps (default) 
4 -15 to 75 milli volts 
s -15 to 30 milli volts 
6 -5 to 5 volts 
7 1 to 5 volts 
8 0 to 20 milliamp 
i) 0 to 50 milliamp 
10-99 Reserved 
100-199 Vendor Specific 
200-255 Reserved 


Input Channel Mode, Attribute 4 


The Input Channel Mode attribute specifies how the analog input signal is used in the 
application. 


0 — Input Signal Not Used. The input signal is not used and the Safe State Value is reported in 
the Safety Analog Input Value to the safety controller. No faults, alarms or warnings are 
evaluated. The Input Point Status data is set to zero. The Fault Reason value is set to 8 to 
indicate that the input point is not used. 


1 — Safety with testing. The input signal is read from the terminal, processed through the 
conditioning and filtering algorithms and reported in the Safety Analog Input Value to the 
safety controller. The signal integrity is verified by the internal test algorithms. If any 
faults are detected, the Input Point Status is set to zero and the Safe State Value is reported 
in the Safety Analog Input Value to the safety controller. The Fault Reason value is set to a 
value that indicates what caused the fault. 
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2 — Standard. The input signal is read from the raw input and processed through the 
conditioning and filtering algorithms and reported in the Safety Analog Input Value to the 
safety controller. The safety verifications are applied to the input signal but the input point 
can not be paired with a safety input point in a dual channel configuration when “Standard” 
mode is selected. 


Input Point Status, Attribute 5 


The Input Point Status attribute provides a status of the safety analog input point. When set 
(=1), the Input Point is operating normally. When cleared (=0), a signal integrity related fault 
has been declared. The Point Fault Reason attribute provides detail about what event caused the 
fault. 


Point Fault Reason, Attribute 6 


The Fault Reason attribute provides a detailed description of what condition was detected that 
caused the Input Point Status attribute to be set to 0. If the Input Point Status is one, the Point 
Fault Reason is also one, Operating Normally. 


Table 5-14.5 Fault Reason Value Definitions 


Value Definition 
0 Reserved 


Operating Normally 


1 
2 Over Range 
3 Under Range 
4 Signal Integrity Failure - The channel has failed a safety related integrity test. 
5 Discrepancy Error 
6 Partner Discrepancy Error 
el Calibration Failure 
8 Input Point Mode is “Input Signal not Used” 
9-99 Reserved 


100-199 vendor specific 
200-255 Reserved 


5-11.5.7 Real Time Sample Period, Attribute 7 


The Real Time Sample Period attribute specifies the time in milliseconds at which the 
application will sample the input data. This value is an internal time that is independent from 
any IO connection RPI. This value may be specified as a constant by the implementation. 
Vendors are free to limit the valid settings as required by the implementation. 
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5-11.5.8 Input Error Latch Time, Attribute 8 


The Input Error Latch Time specifies the minimum time that an input point fault shall be 
latched after the fault condition is detected. If the fault condition clears before the latch time 
expires, the Input Point Status value shall be held at zero and the Point Fault Reason is held at 
the associated value for the latch time duration. If the error condition is cleared after the latch 
timer expires, the Input Point Status andPoint Fault Reason are set to one by the module. A 
value of zero specifies that no latching will occur. 


The following figure illustrates the relationship of the fault event and the Input Error Latch 
Time and the Input Point Status value. 


Figure 5-14.1 Input Point Status and Latch Error Time 
Fault Event Less than Latch Error Time 


Fault event 
Input Error Latch Time 


Input Point Status 


Fault Event Longer than Latch Error Time 


Fault Event 


Input Error Latch Time 
Input Point Status 


Full Scale, Attribute 9 


Value returned to the controller when the Safe State Behavior attribute is set to “Full Scale” 
(1). The Full Scale Value is determined by the Data Type and Input Range. Default value is the 
maximum value of the data type. 
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Safe State Behavior, Attribute 10 


The Safe State Behavior attribute specifies the value that the Safety Analog Input Point should 


report in the Safety Analog Input Value to the safety controller whenever the input channel is 
in the “Safe State”, e.g. a fault in the input or power circuitry is detected. 
Table 5-14.6 Safe State Behavior Definitions 
Value Definition 
0 Use Safe State Value (Default) 
1 Full Scale 
2 Hold Last Value 
3. Continue Sensing 
4-99 Reserved 
100-255 Vendor Specific 


Safe State Value, Attribute 11 


The Safe State Value attribute represents the analog input value that is reported in the Safety 
Analog Input Value to the safety controller whenever the Input Point Status is 0 and the Safe 
State Behavior is Use Safe State Value. The default is zero. 


High and Low Signal, High and Low Engineering Values, Attributes 12-15 


The Safety Analog input Object derives a reading from a physical sensor. The reading is 

converted to the Data Type and Input Range (units) specified for the Analog Input Value 
attribute. The High Signal, Low Signal, High Engineering and Low Engineering attribute 
values are applied to the sensor reading as specified by the following formula. 

Value = (Raw Input Value — Low Signal) * Adjust + Low Engineering 

Adjust = (High Engineering — Low Engineering) / (High Signal — Low Signal) 


The High and Low Signal attributes may be constant, non-settable values depending on the 
implementation. 


Alarm/Warning Status, Attributes 16 


The Alarm/Warning Status attribute is a bit mapped byte that represents the alarm and warning 
status of the Safety Analog Input. The following bits are defined. 


Table 5-14.7 Alarm/Warning Status Bit Definition 


Bit Definition 
0 High Alarm Exception 0 = Fault, 1 = Within range 
1 Low Alarm Exception 0 = Fault, | = Within range 
2 High Warning Exception 0 = Fault, 1 = Within range 
3} Low Warning Exception 0 = Fault, 1 = Within range 
47 Reserved 
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Alarm/Warning Enable, Attributes 17, 22 


The Alarm and Warning Enable attributes allow the user to specify when the process alarms 
and/or warnings are to be monitored. When set to 1, the alarms and warnings are monitored and 
the associated status bits in the Alarm and Warning Status attribute are set to one or zero, as 
appropriate depending on the alarm or warning trip point, hysteresis and settling time 
attributes. 


Alarm/Warning Trip Points, Hysteresis and Settling Time, Attributes 18-21, 23-26 


The Alarm or Warning Trip Point High attribute is the level above which an alarm or warning 
will be declared when the Safety Analog Input Value exceeds this level. 


The Alarm or Warning Trip Point Low attribute is the level below which an alarm or warning 
will be declared when the Safety Analog Input Value is less than this level. 


Before the Alarm and Warning configuration is applied, the values shall be validated to ensure 
that: 


Alarm Trip Point High >= Warning Trip Point High 
Alarm Trip Point Low <= Warning Trip Point Low 
Alarm Trip Point High > Alarm Trip Point Low 
Warning Trip Point High > Warning Trip Point Low 


The Alarm or Warning Hysteresis attribute specifies the amount by which the Safety Analog 
Input Value must transition in order to clear an alarm or warning condition. For example, when 
the Alarm Trip Point High value is 1000 and the Alarm Hysteresis is 2, an alarm will be 
declared then the Safety Analog Input Value exceeds 1000 and will be cleared when the value 
drops below 998. Conversely, when the alarm trip point low value is 100, an alarm will be 
declared then the Safety Analog Input Value drops below 100 and will be cleared when the 
value recovers to 102. 


The Alarm or Warning Settling Time attribute specifies the amount of time that the Safety 
Analog Input Value attribute must exceed the Alarm or Warning Trip Point level before an 
alarm or warning is declared. The Alarm or Warning Settling Time also applies to the clearing 
of the alarm or warning. When the input value returns to within the specified alarm or warning 
value for the Alarm or Warning Settling Time, the affected alarm or warning bit shall be set to 
zero. 
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5-14.2 


Alarm 
hysteresis Trip High 


Warning 
Trip High 


Warning 
Trip Low 


hysteresis Alarm 


iTrip Low 
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Offset-A and Gain Data Type, Attributes 29, 31 


The Offset-A Data Type attribute determines the data type to be used by the Offset-A attribute. 
The implementation may support only those Data Type values needed for its application. If 
Offset-A Data Type is not supported, then the Offset-A data type defaults to INT. 


The Offset-A Data Type attribute uses the enumerated numeric types defined in section 5- 
14.4.1, Data Type, Attribute 1. 


Offset-A and B, Gain and Unity Gain Reference, Attributes 30, 32 - 34 
The Offset-A and Offset-B and Gain attributes are values used to calculate the Safety Analog 
Input Value as shown in section 5-14.4.2. 


Produce Trigger Delta, Attribute 35 


This attribute is used in conjunction with a “Change of State” connection. It specifies the 
amount of change in the Safety Analog Input Value that triggers a Change of State IO 
production. Each time a Change of State production is generated, the value of the Safety 
Analog Input Value attribute is saved and used with the Produce Trigger Delta value to 
determine the next data production. The Produce Trigger Delta is an absolute value. 


Subclass, Attribute 99 


Each instance level subclass defines an application specific (e.g. temperature sensor or flame 
detection sensor) set of attributes, services and behaviors. The range for subclass definitions 
starts at 96 and numbers downward for attributes and 0x63 and numbers downward for object 
specific services. The subclass is defined by the value of its subclass instance attribute. 
Subclass specifications will be added to this object definition as needed. 


Common Services 
The Safety Analog Input Object provides the following Common Services: 


Table 5-14.8 Safety Analog Input Point Object Common Services 


Service | Need in Implementation 


Code Class Instance Service Name Description of Service 

OEhex |Required | Required Get_Attribute_Single | Returns the contents of the specified 
attribute. 

10hex | n/a Conditional! | Set_Attribute_Single | Modifies an attribute value. 

Olhex | Optional | Optional Get_Attributes_All Returns a predefined listing of this 


objects attributes (See the 
Get_Attributes_AII Response definition 
below) 


O2hex |n/a Optional Set_Attributes_All Modifies the contents of the attributes 

of the class or object. 

1. The Set_Attribute_Single service is required if settable Instance Attributes are 
implemented. 


See Appendix A for definition of these services 
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Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply data” 
portion of the Get_Attributes_All response is defined in Volume 1, Chapter 4-5.1. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion (see Chapter 4 for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 


Table 5-14.9 Get_Attributes_All Response Data — Instance Level 


Byte Bit7 Bit 6 Bit 5 Bit4 Bit3 Bit2 Bit 1 Bit 0 
0 Value Data Type Default = C3 
1 Safety Analog Input Value (low byte) 

n+l Safety Analog Input Value (high byte) 


Input Range Default = 3 
Input Channel Mode Default = 0 


0 0 0 0 0 0 0 Input Point 
Status 
Default = 1 


Point Fault Reason Default = 1 


Real Time Sample Period (low byte) Default = 0 
Real Time Sample Period (high byte) 
Input Error Latch Time (low byte) Default = 0 


Input Error Latch Time (high byte) 


Full Scale (low byte) Default = Data Type Maximum 
Full Scale (high byte) 
Safe State Behavior Default = 0 


Safe State Value (low byte) Default = 0 
Safe State Value (high byte) 
Low Signal (low byte) Default = Data Type minimum 


Low Signal (high byte) 


High Signal (low byte) Default = Data Type maximum 
High Signal (high byte) 


Low Engineering (low byte) Default = Data Type minimum 


Low Engineering (high byte) 


High Engineering (low byte) Default = Data Type maximum 


High Engineering (high byte) 


Alarm and Warning Status Default = OxOF 


Alarm Enable Default = 0 


Alarm Trip Point High (low byte) Default = Data Type maximum 
Alarm Trip Point High (high byte) 


Alarm Trip Point Low (low byte) Default = Data Type minimum 


‘Alarm Trip Point Low (high byte) 


Alarm Hysteresis (low byte) Default = 0 


Alarm Hysteresis (high byte) 
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Alarm Settling Time (low byte) Default = 0 


Alarm Settling Time (high byte) 
Warning Enable Default = 0 


Warning Trip Point High (low byte) Default = Data Type maximum 


Warning Trip Point High (high byte) 


Warning Trip Point Low (low byte) Default = Data Type minimum 


Warning Trip Point Low (high byte) 


Warning Hysteresis (low byte) Default = 0 


Warning Hysteresis (high byte) 


Warning Settling Time (low byte) Default = 0 


Warning Settling Time (high byte) 


Overrange (low byte) Default = Data Type maximum 
Overrange (high byte) 


Underrange (low byte) Default = Data Type minimum 


Underrange (high byte) 

Offset-A Data Type Default = C3 
Offset- A (low byte) Default = 0 
Offset- A (high byte) 

Gain Data Type Default = CA 
Gain (low byte) Default = 0 
Gain (high byte) 

Unity Gain Reference (low byte) Default = 1.0 


Unity Gain Reference (high byte) 
Offset-B (low byte) Default = 0 
Offset-B (high byte) 

Produce Trigger Delta (low byte) Default = 0 


Produce Trigger Delta (high byte) 
Subclass Default = 0 


Important: Insert default values for all unsupported attributes and return up to the last 
supported attribute. 
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5-14.5.2 Set_Attributes_All Request 
No settable attributes currently exist at the Class level for the Safety Analog Input Point object. 


At the Instance level, the order of attributes passed in the Set_Attributes_All request is as 
follows: 


Table 5-14.10 Set_Attributes_All Request Data — Instance Level 


Byte Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
0 Value Data Type (1) 


I Input Range (3) 
2 Input Channel Mode (4) 
BE) 


Real Time Sample Period (low byte) (7) 


4 Real Time Sample Period (high byte) 
a 


Input Error Latch Time (low byte) (8) 


6 Input Error Latch Time (high byte) 
w Full Scale (low byte) (9) 


Full Scale (high byte) 
Safe State Behavior (10) 
Safe State Value (low byte) (11) 
Safe State Value (high byte) 
Low Signal (low byte) (12) 
Low Signal (high byte) 
High Signal (low byte) (13) 
High Signal (high byte) 


Low Engineering (low byte) (14) 


Low Engineering (high byte) 


High Engineering (low byte) (15) 


High Engineering (high byte) 
Alarm Enable (17) 
Alarm Trip Point High (low byte) (18) 
Alarm Trip Point High (high byte) 
Alarm Trip Point Low (low byte) (19) 


Alarm Trip Point Low (high byte) 


Alarm Hysteresis (low byte) (20) 


Alarm Hysteresis (high byte) 
Alarm Settling Time (low byte) (21) 


Alarm Settling Time (high byte) 
Warning Enable (22) 
Warning Trip Point High (low byte) (23) 


Warning Trip Point High (high byte) 


Warning Trip Point Low (low byte) (24) 


Warning Trip Point Low (high byte) 


Warning Hysteresis (low byte) (25) 
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Byte | Bit7 


Bit 0 


Warning Hysteresis (high byte) 


Warning Settling Time (low byte) (26) 


Warning Settling Time (high byte) 


Offset- A (low byte) (30) 


Offset- A (high byte) 


Gain (low byte) (32) 


Gain (high byte) 


Offset-B (low byte) (34) 


Offset-B (high byte) 


Produce Trigger Delta (low byte) (35) 


Produce Trigger Delta (high byte) 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 


Object-specific Services 


The Safety Analog Input Object provides the following Object Specific Services: 


Table 5-14.11 Safety Analog Input Point Object Specific Services 


Service | Need in Implementation 
Code Class Instance Service Name Description of Service 

4Bhex | n/a Optional Zero_Adjust Causes the module to modify the offset 
value used for calculating the Safety 
Analog Input Value. 

4Chex | n/a Optional Gain_Adjust Causes the module to modify the gain 
value used for calculating the Safety 
Analog Input Value. 


Important: Services are only accepted when the Safety Supervisor is in the Configuring or 


Waiting 


‘or TUNID state. 


Zero_Adjust and Gain_Adjust Services 


The Zero_Adjust and Gain_Adjust services are used to cause the Safety Analog Input to update 
the offset and gain values based on manufacturer specific algorithms. The target value specified 
in the service request represents the actual parametric measurement that the physical sensor 

e time of the calibration request. 


should be reporting at tl 


Table 5-14.12 Zero_Adjust Request Service Data Parameters 


Parameter | Required Data Type Description Semantics of Values 

Target Optional Specified by Data Target value for the | The value to which the Safety 

Value Type attribute zero calibration Analog Input Value attributes will 
be set. Default = 0 
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Table 5-14.13 Gain_Adjust Request Service Data Parameters 


Parameter | Required Data Type Description Semantics of Values 

Target Required | Specified by Data | Target value for The value to which the Safety 

Value Type attribute the zero calibration | Analog Input Value attribute will be 
set. 


When the requested service has been completed successfully, a success response is returned. If 
the request fails, one of the following error responses is returned. 


Table 5-14.14 Error Responses 


General Status Extended Status Description 
10 na Device State Conflict, can not accept request in current state 
20 ol Calibration Failure, unable to apply the specified values 
Behavior 


This section defines the required behaviors of the Safety Analog Input Point. 


Type of Safety Inputs 


The following table defines the type of safety inputs supported by the Safety Analog Input 
Point Object. The effects on the Raw Input Value, Analog Input Value, Safety Analog Input 
Value and Status are shown. The SAIP is designed to execute the selected Safe State Behavior 
when a safety related fault condition is detected. 


Table 5-14.15 Supported Safety Input Types 


Input Channel Type Safety Input Type 
Q= Input Signal Not | Raw Input Value Undefined 
Used Analog Input Value Undefined 


Safety Analog Input Value 


Safe State Behavior Value 


Input Point Status 


Always 0, = Invalid 


1 = Safety, with SIL 
integrity testing 


Raw Input Value 


Input Terminal Value 


Analog Input Value 


Set to resulting value after conditioning 
and filtering 


Safety Analog Input Value 


Set to resulting value after conditioning 
and filtering, and SIL integrity testing. Set 
to Safe State Value if fault is detected. 


Input Point Status 


0 = Faulted/Invalid 
1 = Valid 


2 = Standard, no SIL 
integrity testing 


Raw Input Value 


Input Terminal Value 


Analog Input Value 


Set to resulting value after conditioning 


and filtering 

Safety Analog Input Value Set to resulting value after conditioning 
and filtering 

Input Point Status 0 = Faulted/Invalid 


1 = Valid 
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5-14.7.2 Safety Analog Input Evaluation 


The following diagram depicts one possible flow on Safety Analog Input Evaluation 
processing, 


Figure 5-14.3 Safety Analog Input Evaluation Flow 
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The details of the test evaluation are product specific but generally include verification of 
signal integrity, validity and accuracy. Test may also cover signal path connectivity, strength 
or other transmission characteristics. The Safety Analog Input Value shall be set according to 
Safe State Behavior attribute when the Input channel mode is “Not Used”. 


The following diagram defines the behavior of the Input Evaluation process shown above. 


Figure 5-14.4 Safety Analog Input Evaluation 
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5-15 Safety Analog Input Group Object 
Class Code: 4Anhex 
The Safety Analog Input Group Object (SAIG) binds a group of Safety Analog Input Points 
(SAIP) in a module. All points bound to the group share all attributes contained in the group. If 
an attribute is shared (e.g. if points have the same configuration attributes AND the same 
attribute values) across more than one Safety Analog Input Point, then that attribute can be 
contained in a Safety Analog Input Group. A Safety Analog Input Point can be bound to more 
than one Safety Analog Input Group, but the attrbiutes that are common at the group level must 
have the same values in each group. Configuration attributes contained in the group are Get 
only in the individual SAIP object. 
The list of Safety Analog Input points bound to the group is static and is a Get—only attribute of 
the group. 
When to use the Safety Analog Input Group Object: 
e When a single attribute is shared among many input points. 
e To more efficiently access data (services that affect all members of the group can be 
supported by the SAIG). 
Figure 5-15.1 Safety Analog Input Group Object Application 
coo 
§-15.1 Revision History 
The table below represents the revision history of this object: 
Table 5-15.1 Safety Analog Input Group Object Revision History 
Revision Reason for object definition update 
ol Initial Definition at First Release of Specification 
5-15.2 Class Attributes 
Table 5-15.2 Safety Analog Input Group Object Class Attributes 
Attribute Need in Access | Name Data Type Description of | Semantics of Values 
ID Implementation | Rule Attribute 
1 thru7 These class attributes are optional and are described in Chapter 4 of this specification. 
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5-15.3 Instance Attributes 


Table 5-15.3 Safety Analog Input Group Object Instance Attributes 


AttrID| Need in Access | NV Attribute Data Description of Semantics of Values 
Implem Rule Name Type Attribute 
1 Optional Get NV | Number of USINT | Number of Safety 
Bound Analog Input points 
Instances bound to this group 
2 Optional Get NV | Binding Array | List of Instance Ids 
of of Safety Analog 
UINT | Input points bound 
to this group 
3 Optional Set! NV | Data Type USINT | Determines the data | C3 = INT (default) 
type of the Safety See Appendix C-6.1 
Analog Input Value 
attribute for all 
members of this 
group 
4 Optional Set! NV | Input Range USINT | Input range the See Semantics section. 
point is operating in 
5 Optional Get V_ | Input Status BOOL | Logical AND of the | 0 = One or more group 
Input Point Status | members are faulted 
of the Analog Input | | = pata from all 
Points in the Group | members is valid. 
6 Optional Set NV | Input Error UNIT | Minimum time a 0- 65535 ms, 
Latch Time Safety Input error | gefault = 1000 
will be latched for. |. 
See Semantics section. 
9 Optional Set NV | Full Scale INT or | The value of Full The value of Safety 
based | Scale for the sensor | Analog Input Value 
on Data corresponding to the 
Type Full Scale calibrated 
measurement of the 
sensor. Default = 
Maximum value for the 
Data Type. 
8 Optional Set! NV | Safe State USINT | Defines behavior 0 = Use Safe State 
Behavior for value reporting | Value, default. 
when faulted. See Semantics section. 
2) Optional Set! NV | Safe State INT or | Safe State Analog 0 = default. 
Value based | Input value. 
on Data 
Type 
10 Optional Get V_ | Alarm and BYTE | Logical OR of all 0 = No alarms or 
Warning Status Alarm and Warning | warnings in the group. 
Status of the analog |} = Alarm or Warning in 
points in the Group. | at jeast one group 
member. 
11 Optional Set NV | Alarm Enable |BOOL | Enable Alarm 0 = Disable, default 
Status Checking 1 =Enable 
12 | Optional Set NV | Alarm Trip INT or | Specifies the Value | See Semantics section, 
Point High based | above which an Default = Max value for 
on Data | Alarm Condition Data Type 
Type will occur. 
-5-111- 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


5-15.4 


5-15.4.1 


5-15.4.2 


Attr ID 


Safety Analog Input Group Object, Class Code: 4A Hex 


Attribute 


Data 


Need in Access | NV Description of Semantics of Values 
Implem Rule Name Type Attribute 
13 | Optional Set NV | Alarm Trip INT or | Specifies the Value | See Semantics section, 
Point Low based | below which an Default = Min value for 
on Data | Alarm Condition Data Type 
Type will occur. 
14 | Optional Set NV | Alarm INT or | Specifies the 0 = default 
Hysteresis based | amount by which | See Semantics section. 
on Data | the Safety Analog 
Type Input Value must 
recover to clear the 
Alarm condition. 
15 | Optional Set NV | Alarm Settling | INT or | Determines the time | Time in milliseconds 
Time based | that the Value must | 0 = default 
on Data | exceed the Alarm | See Semantics section. 
Type Trip Point before a 
Warning Condition 
will occur. 
16 | Optional Set NV | Warning BOOL | Enable Alarm 0 = Disable, default 
Enable Status Checking 1 =Enable 
17 | Optional Set NV | Warning Trip |INT or | Specifies the Value | See Semantics section, 
Point High based | above which an Default = Max value for 
on Data | Alarm Condition Data Type 
Type __| will occur. 
18 Optional Set NV | Warning Trip | INT or | Specifies the Value 
Point Low based | below which an Default = Min value for 
on Data | Alarm Condition Data Type 
Type will occur. 
19 | Optional Set NV | Warning INT or | Specifies the 0 = default 
Hysteresis based | amount by which | See Semantics section. 
on Data | the Safety Analog 
Type Input Value must 
recover to clear the 
Warning condition 
20 | Optional Set NV | Warning INT or | Determines the time | Time in milliseconds 
Settling Time | based | that the Value must | 0 = default 
on Data | exceed the Warning | See Semantics section. 
Type Trip Point before a 


Warning Condition 
will occur. 


1. Attribute may be implemented as get only. Refer to Safety Analog Input Point. 


Semantics 


This section defines the semantics of the Safety Analog Input Group object attributes. 


Number of Bound Instances, Attribute 1 


Number of Safety Analog Input points bound to the group. 


Bound Instances, Attribute 2 


List of instance Ids of Safety Analog Input points bound to the group. 
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5-15.4.10 
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Data Type, Attribute 3 

The Data Type attribute determines the data type to be used by all members of the group. Refer 
to the Safety Analog Input Point object. 

Input Range, Attribute 4 


The Input Range attribute determines the set of analog values within which the inputs may 
operate. The value of the Input Range affects the default and legal values that other attributes 
may have. Refer to the Safety Analog Input Point object. 


Input Status, Attribute 5 
Status is a simple logical AND of the Input Point Status of each SAIP instance bound to the 
Safety Analog Input Group. 


Input Error Latch Time, Attribute 6 


The Input Error Latch Time specifies the minimum time that an input point fault shall be 
latched after the fault condition is detected for all members of the group. Refer to the Safety 
Analog Input Point object. 


Full Scale, Attribute 7 


Value returned to the controller when the Safe State Behavior attribute is set to “Full Scale” 
(1). The Full Scale Value is determined by the Data Type and Input Range. Deafult value is the 
maximum value of the data type. 


Safe State Behavior, Attribute 8 


The Safe State Behavior attribute specifies for all members of the group the action that the 
Safety Analog Input Point should report to the safety controller whenever the input channel is 
in the “Safe State”, e.g. a fault in the input or power circuitry is detected. Refer to the Safety 
Analog Input Point object. 


Safe State Value, Attribute 9 


The Safe State Value attribute specifies for all members of the group the analog input value 
that is reported to the safety controller whenever the Input Point Status is 0 and the Safe State 
Behavior is Use Safe State Value. The default is zero. 


Alarm and Warning Status, Attribute 10 


Status is a simple logical OR of the Alarm and Warning Status of each SAIP instance bound to 
the Safety Analog Input Group. 
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Alarm/Warning Enable, Attributes 11, 16 


The Alarm and Warning Enable attributes allow the user to specify when the process alarms 
and/or warnings are to be monitored. When set to 1, the alarms and warnings are monitored and 
the associated status bits in the Alarm and Warning Status attribute are set to one or zero, as 
appropriate depending on the alarm or warning trip point, hysteresis and settling time attributes. 


Alarm/Warning Trip Points, Hysteresis and Settling Time, Attributes 12-15, 17-20 


The Alarm or Warning Trip Point High attribute is the level above which an alarm or warning 
will be declared when the Safety Analog Input Value exceeds this level. 


The Alarm or Warning Trip Point Low attribute is the level below which an alarm or warning 
will be declared when the Safety Analog Input Value is less than this level. 


Before the Alarm and Warning configuration is applied, the values shall be validated to ensure 
that: 

e Alarm High Trip Point >= Warning Trip Point High 

e Alarm High Trip Low <= Warning Trip Point Low 

e Alarm High Trip Point > Alarm High Trip Low 

e Warning Trip Point High > Warning Trip Point Low 


The Alarm or Warning Hysteresis attribute specifies the amount by which the Safety Analog 
Input Value for all members in the group must transition in order to clear an alarm or warning 
condition. Refer to the Safety Analog Input Point object. 


The Alarm or Warning Settling Time attribute specifies the amount of time that the Safety 
Analog Input Value attribute for all members in the group must exceed the Alarm or Warning 
Trip Point level before an alarm or warning is declared. The Alarm or Warning Settling Time 
also applies to the clearing of the alarm or warning. 

Common Services 


The Safety Analog Input Group Object provides the following Common Services: 


Table 5-15.4 Safety Analog Input Group Object Common Services 


Service Need In Implementation Service Name Description of Service 
Code Class Instance 
OE hex Conditional ' | Required Get_Attribute_Single | Returns the contents of the specified attribute 
10 hex N/A Conditional” | Set_Attribute_Single | Modifies an attribute value 
O1 hex Optional Optional Get_Attributes_All Returns a predefined listing of this object's 


attributes (See the Get_Attributes_All 
Response definition below) 


O2hex | N/A Optional Set_Attributes_All Modifies the contents of the attributes of the 
class or object. 


1. The Get_Attribute_Single service is REQUIRED if any attributes are implemented. 
2. The Set_Attribute_Single service is required only if any Settable Attributes are implemented. 


See Appendix A for definitions of these services. 
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5-15.5.1 | Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply data” 
portion of the Get_Attributes_All response are defined in Volume 1, Chapter 4. 


Important: Insert default values for all unsupported attributes. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion of the Get_Attributes_AII response is as follows: 


Table 5-15.5 Get_Attributes_All Response Data — Instance Level 


Byte | Bit7 Bits | Bits | Bid | Bis | Bit2 | Bit |  BitO 
0 Number of Bound Instances (default = 0) 
1 Binding : Instance ID #1 (low byte) 
2 Binding : Instance ID #1 (high byte) 


Binding : Instance ID #m (low byte) 
Binding : Instance ID #m (high byte) 
Data Type (default = C3) 
Input Range Default = 3 


0 0 0 0 0 0 0 Input Status 
Default = 1 


Input Error Latch Time (low byte) (default = 0) 
Input Error Latch Time (high byte) 


Full Scale (low byte) Default = Data Type Maximum 


Full Scale (high byte) Default = Data Type Maximum 
Safe State Behavior =(default = 0) 
Safe State Value (low byte) (default = 0) 
Safe State Value (high byte) (default = 0) 
Alarm/Warning Status (default = 0) 
Alarm Enable Default = 0 
Alarm Trip Point High (low byte) Default = Data Type maximum 
Alarm Trip Point High (high byte) 
Alarm Trip Point Low (low byte) Default = Data Type minimum 


Alarm Trip Point Low (high byte) 


Alarm Hysteresis (low byte) (default = 0) 


.Alarm Hysteresis (high byte) (default = 0) 
Alarm Settling Time (low byte) (default = 0) 
-Alarm Settling Time (high byte) (default = 0) 

Warning Enable Default = 0 


Warning Trip Point High (low byte) Default = Data Type maximum 


Warning Trip Point High (high byte) 


Warning Trip Point Low (low byte) Default = Data Type minimum 


Warning Trip Point Low (high byte) 
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Warning Hysteresis (low byte) (default = 0) 


. Warning Hysteresis (high byte) (default = 0) 


Warning Settling Time (low byte) (default = 0) 


Warning Settling Time (high byte) (default = 0) 


Important: Insert default values for all unsupported attributes and return up to the last 
supported attribute. 


Important: If the instance attribute "Number of Bound Instances” is not supported, the default 
value of zero is to be inserted into the response byte array and no Binding data will follow. 


5-15.5.2 Set_Attributes_All Request 


No settable attributes currently exist at the Class level for the Safety Analog Input Group 
Object. 


At the Instance level, the order of attributes passed in the “Object/service specific request data” 
portion of the Set_Attributes_All request is as follows: 


Table 5-15.6 Set_Attributes_All Request Service Data — Instance Level 


Byte Bit7 Bit 6 Bit 5 Bit 4 | Bit 3 Bit 2 Bit 1 Bit 0 
0 Data Type (3) 
1 Input Range Default = 3 
2 Input Error Latch Time (low byte) 
3 Input Error Latch Time (high byte) 
4 Full Scale (low byte) Default = Data Type Maximum 


Full Scale (high byte) Default = Data Type Maximum 


Safe State Behavior 


Safe State Value (low byte) 
Safe State Value (high byte) 
Alarm Enable 


Alarm Trip Point High (low byte) 
Alarm Trip Point High (high byte) 


Alarm Trip Point Low (low byte) 


Alarm Trip Point Low (high byte) 


Alarm Settling Time (low byte) 


-Alarm Settling Time (high byte) 


Alarm Hysteresis (low byte) 


-Alarm Hysteresis (high byte) 


Warning Hysteresis (low byte) 


. Warning Hysteresis (high byte) 
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Warning Enable 


Warning Trip Point High (low byte) 


Waring Trip Point High (high byte) 


Warning Trip Point Low (low byte) 


Warning Trip Point Low (high byte) 


Warning Settling Time (low byte) 


Warning Settling Time (high byte) 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 
Object-specific Services 


The Safety Analog Input Group Object provides no Object—specific services. 


Behavior 


The primary purpose of the Safety Analog Input Group Object is to bind Safety Analog Input 
Points. 


An attribute of the SAIG modifies the behavior or reports additional status information of all 
SAIPs bound to the group. 


The State Transition Diagram below provides a graphical description of the events and 
corresponding state transitions. A subset of the states and events may be supported in an 
application, but the behavior must be consistent. 


The states shown are equivalent to the following: 


Table 5-15.7 Safety Analog Input Group Object State Definitions 


This state Is equivalent to 
Non-Existent | a module without power 


a module that has an unrecoverable fault (e.g. processor watchdog timeout) 


a major reconfiguration of the module (e.g. NVS Update) 


Binding when analog input points are added or bound to each predefined Safety Analog Input 
Group instance (executed as part of Power Up cycle) 


Run the point at which Get and Set attribute services can be used to access the attributes of 
the Group Object 
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Figure 5-15.2 State Transition Diagram for Safety Analog Input Group Object 


Non-Existent }¢e Power Down 
(any state) 

Power Up 

Vv 

Binding 

Binding 

y Established 

Run 


5-15.7.1 Attribute Access Rules 


All attributes are gettable or settable according to their attribute access rules. The Settable 
attributes are only settable when the Safety Supervisor is in the Configuring state. 


5-15.7.2 Input Status Attribute 


The Input Status attribute is simply a logical AND of each individual Input Point Status for all 
points bound to the group. 


5-15.7.3. Alarm and Warning Status Attribute 


The Alarm and Warning Status attribute is simply a logical OR of each individual Alarm and 
Warning Status for all process failures or alarm conditions for all points bound to the group. 
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5-16.2 


5-16.3 


Safety Dual Channel Analog Input Object, Class Code: 4Brex 


Safety Dual Channel Analog Input Object 
Class Code: 4Bhex 


The Safety Dual Channel Analog Input (SDCAI) Object models a pair of safety analog input 
channels as Safety Dual Channel Analog Inputs in a product. This object must be used in 
conjunction with two instances of a Safety Analog Input Point Object. This object can be used 
in any device that contains two or more safety analog inputs. Note that the term “input” is 
defined from the network’s point of view. An input will produce data on the network. 


The main feature of the Safety Dual Channel Analog Input is that it allows a pair of diverse 
analog input values to be monitored simultaneously. This provides signal level integrity for the 
resulting input by running various SIL integrity tests on the input signals before reporting the 
input values to the control system. Whenever a discrepancy fault is detected, a fault state is 
declared and a discrepancy value is reported to the control system. 


Revision History 


This is the initial release of this object. The table below represents the revision history: 


Table 5-16.1 Safety Dual Channel Analog Input Object Revision History 


Revision Reason for object definition update | 
ol Initial Definition at First Release of Specification. CIP Safety 2.3 | 


Class Attributes 


Table 5-16.2 Safety Dual Channel Analog Input Object Class Attributes 


Attr Need in Access NV Name Data Description of 
ID Implem Rule Type Attribute 


Semantics of Value | 


thru See the Volume 1, Chapter 4-9.1 for a description of the optional, reserved class attributes. 


Instance Attributes 


Table 5-16.3 Safety Dual Channel Analog Input Object Instance Attributes 


AttrID| Need in Access | NV Attribute Data Description of Semantics of Values 


Implem Rule Name Type Attribute 
1 Required Set NV | Dual Channel | USINT | Selects the mode for | 0: Single Channel 
Mode the two channels of | (default) 


the Safety Dual 


Channel Analog ¥ Dual Channel 
Input. Equivalent 
2: — 255: Reserved 
2 Optional Get V_ | Dual Channel |BOOL | Status of the Dual 0: Discrepancy Detected 
Evaluation Channel evaluation |}. alia 
Status a 
tas This is Safety Data, 
Safety State Value = 0 
— 5-119 — 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 5: Object Library 


5-16.4 


5-16.4.1 


Attr ID 
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Data 


Need in Access | NV Attribute Description of Semantics of Values 
Implem Rule Name Type Attribute 
3 Required Set! NV | Discrepancy UINT | The time limit at Range: 0 to 65565, in 
Timer which the input milliseconds 
discrepancy Default = 0, no 
becomes an error. monitoring 
4 Required Set! NV |Member One |USINT | Instance Id of one | Default = 0, no pairing 
of the pair of Safety 
Analog Input Point 
(SAITP) objects that 
forms the Safety 
Dual Channel Input. 
(Channel A) 
5 Required Set! NV |Member Two | USINT | Second member of | Default = 0, no pairing 
the dual channel 
safety input pair. 
(Channel B) 
6 Required Set! NV | Discrepancy INT or | Allowed difference | Default = 0, no 
Deadband based | for the channel A Deadband 
on and B values See Semantics 
SAIP 
Data 
Type 
a Optional Set! NV | Discrepancy USINT | Defines behavior 3 = Continue Sensing, 
Behavior for value reporting | default. 
when discrepancy — | see Semantics section. 
occurs. 
8 Optional Set! NV |Discrepancy [INT or | Analog Input value | 0 = default. 
Value based | when discrepancy 
on Data | occurs. 
Type 


1. May be implemented as Get only. 


Semantics 


This section defines the semantics of the Safety Dual Channel Analog Input object attributes. 


Dual Channel Mode, Attribute 1 


The Dual Channel Mode attribute specifies how the analog input signal is used in the 


application. 


0 — Single. No dual Channel Evaluation is applied. 


1 — Dual Channel Equivalent. The primary input signal is compared to the secondary input 
signal and evaluated for equality as determined by the Discrepancy Deadband and 
Discrepancy Timer. 
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Dual Channel Evaluation Status, Attribute 2 


The Dual Channel Evaluation Status attribute provides a status of the Safety Dual Channel 
Analog Input. When set to 1, the Input Point is operating normally. When set to 0, a 
discrepancy fault has been declared. The Dual Channel Evaluation Status is associated with the 
bound SAIP Input Point Status. When a discrepancy fault is declared, the associated Input 
Point Status is set to 0 for both Member | and Member 2. The Point Fault Reason is set to 
Discrepancy Error (5) for Member 1| and Partner Discrepancy Error (6) for Member 2. 


Discrepancy Timer, Attribute 3 


The Discrepancy Timer attribute defines how the discrepancy time monitoring is applied. If 
Discrepancy Timer is set to zero, no discrepancy time is applied. If non-zero, no discrepancy 
fault is declared until after the discrepancy timer has expired. The discrepancy fault is cleared 
when the signals return to an acceptable Discrepancy Deadband value for the Discrepancy 
Timer time. The Discrepancy Behavior value will be returned to the control system when the 
discrepancy exists for longer than the Discrepancy Timer time. 


Member One, Attribute 4 


The Member One attribute defines the first instance of the Safety Analog Input Pair. If a 
discrepancy fault is declared, this input shall be assigned the Discrepancy Error in the Fault 
Reason attribute of the SAIP. 


When used in the Dual mode, both members of the pair must have similar configurations for 
the following attributes of the underlying SAIP instances. How this is accomplished is vendor 
specific. 

1. Data Type (1) 

2. Input Range (3) 

3. Input Channel Mode (4) 

4. Real Time Sample Period (7) 


Member Two, Attribute 5 


The Member Two attribute defines the second instance of the Safety Analog Input Pair. If a 
discrepancy fault is declared, this input shall be assigned the Partner Discrepancy Error in the 
Fault Reason attribute of the SAIP. 


Discrepancy Deadband, Attribute 6 


The Discrepancy Deadband attribute defines a difference value to be used when evaluating the 
two paired analog input signals. The value is an absolute value of the maximum difference to 
be accepted when the two Safety Analog Input Values are compared. If a discrepancy occurs, 
the Discrepancy Timer time will be applied before the safe state data value is returned in the 
Safety Analog Input Values for the Dual Channel Input pair. 
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Discrepancy Behavior, Attribute 7 

The Discrepancy Behavior attribute specifies the value that the Safety Analog Input Points in 
the Dual Channel pair should report in the Safety Analog Input Value to the safety controller 
whenever a discrepancy condition is detected. 


Table 5-16.4 Discrepancy Behavior Definitions 


Value Definition 
0 Use Discrepancy Value 
1 Full Scale 
2 Hold Last Value 
3 Continue Sensing (Default) 
4-99 Reserved 
100-255 Vendor Specific 


Discrepancy Value, Attribute 8 
The Discrepancy Value attribute represents the analog input value that is reported in the Safety 


Analog Input Value to the safety controller whenever a discrepancy condition is detected and 
the Discrepancy Behavior is Use Discrepancy Value. The default is zero. 


Common Services 
The Safety Dual Channel Analog Input Object provides the following Common Services: 


Table 5-16.5 Safety Dual Channel Analog Input Object Common Services 


Service | Need in Implementation 


Code Class Instance Service Name Description of Service 

OEhex | Conditional’ | Required |Get_Attribute_Single | Returns the contents of the specified 
attribute. 

Olhex | Optional Optional | Get_Attributes_All Returns a predefined listing of this 


objects attributes (See the 
Get_Attributes_All Response definition 
below) 

O2hex |n/a Optional | Set_Attributes_All Modifies the contents of the attributes 
of the class or object. 


1, Required if any attributes are supported. 


See Appendix A for definition of these services 


Get_Attributes_All Response 


At the Class level, the order of the attributes returned in the “Object/service specific reply data” 
portion of the Get_Attributes_All response is defined in the CIP Specification, Volume 1, 
Chapter 4-5.1. 


At the Instance level, the order of the attributes returned in the “Object/service specific reply 
data” portion (see Chapter 4 for a description of the Service Data field) of the 
Get_Attributes_All response is as follows: 
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Table 5-16.6 Get_Attributes_All Response Data — Instance Level 


Byte Bit7 Bit 6 Bit 5 Bit4 Bit 3 Bit 2 Bit 1 Bit 0 
0 Dual Channel Mode Default = 0 
1 Dual Channel Evaluation Status Default = 0 
2 Discrepancy Timer (high byte) Default = 0 
3 Discrepancy Timer (low byte) 
4 Member One Default = 0 
s Member Two Default = 0 
6 Discrepancy Deadband (high byte) Default = 0 
n Discrepancy Deadband (low byte) 
n+1 Discrepancy Behavior Default = 3 
n+2 Discrepancy Value (high byte) Default = 0 
n43 Discrepancy Value (low byte) 


Important: Insert default values for all unsupported attributes. 


Set_Attributes_All Request 


No settable attributes currently exist at the Class level for the Safety Dual Channel Analog 
Input object. 


At the Instance level, the order of attributes passed in the Set_Attributes_AII request is as 
follows: 


Table 5-16.7 Set_Attributes_All Request Data — Instance Level 


Byte Bit7 Bit 6 Bit 5 Bit4 Bit3 Bit 2 Bit 1 Bit 0 
0 Dual Channel Mode (1) 
1 Discrepancy Timer (high byte) (3) 
2 Discrepancy Timer (low byte) 
3 Member One (4) 
4 Member Two (5) 
5 Discrepancy Deadband (high byte) (6) 
n Discrepancy Deadband (low byte) 
n+l Discrepancy Behavior (7) 
n+2 Discrepancy Value (high byte) (8) 
n+3 Discrepancy Value (low byte) 


Important: The Set_Attributes_All service is to be supported only if all settable attributes 
shown above are implemented as settable. 


Object-specific Services 


The Safety Dual Channel Analog Input Object provides no Object—specific services. 
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5-16.7.1 Safety Dual Channel Input Evaluation 


When instance attribute “Dual Channel Mode” (Attribute 1) is set to single, the Safety Dual 
Channel Analog Input object instance has no behavior beyond the instances of the Safety 
Analog Input Point object. 


When instance attribute “Dual Channel Mode” is set to equivalent, there is an interaction 
between the SDCAI object instance and the two SAIP member instances. The following 
diagram illustrates this relationship. It depicts the flow of the Dual Channel Evaluation 
behavior when the “Dual Channel Mode” instance attribute is set to Equivalent. 


Figure 5-16.1 Overview of Dual Channel Evaluation Behavior 
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The Dual Channel Evaluation Behavior is described in terms of the following: 


1. Single channel evaluation of channels 1 and 2 


i) 


Discrepancy Evaluation 
3. Dual Channel Evaluation 


The Single Channel Evaluation Behavior is defined within the Safety Analog Input Point object 
for both members used in the Safety Dual Channel Analog Input object instance. 
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5-16.7.2 


Safety Dual Channel Analog Input Object, Class Code: 4Brex 


Discrepancy Evaluation 


From a behavioral perspective, the Discrepancy Evaluation portion of the SDCAI object takes 
the following inputs: 


1. Safety Analog Input Value attribute of Member | - Single Channel Evaluation 
2. Safety Analog Input Value attribute of Member 2 - Single Channel Evaluation 
3. Discrepancy Deadband attribute of the SDCAI object 

4. Discrepancy Timer attribute of the SDCAI object (Time) 


From a behavioral perspective, the Discrepancy Evaluation produces the following outputs: 


1. Dual Channel Values — When the respective Safety Analog Input values are within the 
specified Discrepancy Deadband, the input values are reported in the in the Safety Analog 
Input Values for the Dual Channel Input pair. If a discrepancy error is detected, the input 
values reported are determined by the setting of the Discrepancy Behavior attribute of the 
SAIP. Both members of the dual channel pair shall have the same behavior. Refer to Figure 
5-11.7-3 for further clarification. 


2. Dual Channel Evaluation Status instance attribute of the SDCAT object (Ok or Alarm) 


The following diagram illustrates the Discrepancy Evaluation behavior for Dual Channel 
Modes when set to Equivalent. 
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Figure 5-16.2 Dual Channel Mode = Equivalent 


Legend: 


Equal = |Member 1 — Member 2] “Safety Analog Input Value” is within 
the Discrepancy Deadband 

Not Equal = |Member 1 — Member 2| “Safety Analog Input Value" is 
outside of Discrepancy Deadband 

DCES = “Dual Channel Evaluation Status” 

Value = Each Channel Value is reported 


—— i __* 
Dual Chan. Values = Safety 


DCES = Ok 
. Not Equal 
Dual Chan. Values = Value 
\ DCES = Ok 
\ Discrepancy Timer = Start 
ae 
Executing 
Executing Alarm 
Wait 
Equal. ae » 
Discrepancy Timer = Start_—~ \ 
/ Dual Chan, Values = -~ \ 
Safety ee \ 
x a Not Equal. 
Equal. OCES= -— ao = 
Dual Than Values = Value Alam Discrepenice Tiner 5) : 
Ee a Dual Chan. Values =| Safety 
DEES Ox = DCES = Alarm 
\ y A fet eat i M4 
\ “Discrepancy Timer = Start SS / 
\ Dual Chan. Values = Safety 
Executing DCES = Alarm 
Equal Wait 
a ok a 
a 
Equal. 


Discrepancy Timer = Start 
Dual Chan. Values = Safety 
DCES = Alarm 


5-16.7.3. Dual Channel Evaluation 


From a behavioral perspective, the Dual Channel Evaluation portion of the SDCAI object takes 
the following inputs: 


1. Input Point Status attribute of Member 1| - Single Channel Evaluation 
Input Point Status attribute of Member 2 - Single Channel Evaluation 
Point Fault Reason attribute of Member 1| - Single Channel Evaluation 
Point Fault Reason attribute of Member 2 - Single Channel Evaluation 


Dual Channel Values that resulted from the Discrepancy Evaluation 


oe Ss 


Dual Channel Evaluation Status instance attribute of the SDCI object that resulted from the 
Discrepancy Evaluation (Ok or Alarm) 
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From a behavioral perspective, the Dual Channel Evaluation produces the following outputs: 


1. The Safety Input Point Value, Input Point Status, and Point Fault Reason attributes for 
Member | and Member 2 Safety Analog Input Point instances. 


The following table illustrates the Dual Channel Evaluation behavior for Dual Channel Modes 
when set to Equivalent. 


Table 5-16.8 Dual Channel Evaluation Behavior 


m Discrepane Results applied to both Member 1 and Member 2 attributes: 
si tare ee “Safety Analog Input Value”, “Input Point Status”, and “Point 
Evaluation Fault Reason” 
Member 1| Member2 Member 1 & | Member 1 & 
Dual —_| Dual Channel Memberl | Member2 
Input Input Ch i ‘Evalaati Member 2 Member 2 
Point Point i eA usd Safety Analog| Input Point | Point Fault | Point Fault 
Status Status Input Value Status Reason Reason 
Ok Ok Normal Ok Normal OK 0x00 0x00 | 
; Discrepancy SCE-1 Point 
Alarm Ok x x Value Alarm Raut Resi 0x05 
Discrepanc ee 
Ok Alarm x x ee Alarm 0x05 Point Fault 
Value 
Reason 
3 A SCE-2 
Alarm Alarm % i ae Alarm SCE-I Point | point Fault 
‘alue Fault Reason 
Reason 
Ok Ok Discrepancy Alarm ' Discoapancy, Alarm Ox0S 0x06 
Value 
x = don’t care 
SCE-1 = Single Channel Evaluation- Member 1 
SCE-2 = Single Channel Evaluation- Member 2 
Normal = Both Channels reporting normally 


1. If Discrepancy Timer is not expired, Dual Channel value is Normal. Otherwise Dual Channel Value is Safe. 
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Volume 5: CIP Safety 


Chapter 6: Device Profiles 
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6-2 


6-2.1 


6-2.2 


Safety Device Profiles 


This chapter contains the Safety Device profiles. 


Safety State Definition 


In safety systems, it is necessary to define the safety states that are present in the system. 
When using the CIP Safety Networks the common safety states will be defined in this section 
unless otherwise noted. 


Digital //O 
SRS48 The default safety state for digital inputs and outputs shall be off. 


This means that digital inputs in the safety state shall report an off or zero condition along with 
fault status indicating that devices are in the safety state. Digital outputs that are in a safety 
state shall be set to off or zero volts. Digital Outputs shall also report a safety condition on 
their diagnostic information. 


An optional state for digital inputs and outputs may be provided. This functionality should 


allow the affected inputs outputs to maintain last state. This option should be user configurable 
and the default set by the manufacturer shall be the off or zero state. 


Analog I/O 

The default for both analog inputs and outputs should be the value that corresponds to a zero 
state or the lowest value within the range of the device. This value should represent a zero to 
the user. 


An optional state for analog inputs and outputs may be provided. 
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Baseline Safety Device 


All Safety Device Profile definitions shall contain, at a minimum, a basic level of safety 
functionality. A complete safety profile definition is built off of this baseline. The baseline 
safety functionality is defined as one which contains a “baseline” Safety Supervisor (refer to 
Section 5-1.3) for high-integrity device control and one or more Safety Validator instances for 
high-integrity safety I/O connections. 


It is optional for baseline safety profiles to support the SNCT implementation of the Safety 
Supervisor, but is highly recommended since the profile then includes a common, TUV- 
certified configuration solution. All safety profiles shall define which level (i.e. Baseline or 
SNCT) of Safety Supervisor is required. 


Figure 6-3.1 Baseline Safety Device 
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6-4 


6-5 


Rules for Safety Profiles 


If the safety profiles defined here are not suitable for a device, the device manufacturer shall 
define a vendor specific profile and extended device type. 


Safety objects cannot be added to an existing standard profile and use that existing profile 
device type; a new device profile shall be created for safety. 


All safety device profiles created shall have the word “Safety” as the first word in the name. 


Safety Manual Requirements 


This section will contain some of the specific requirements that must be contained in the user 
safety manual for devices which use the CIP Safety Network Protocol. These requirements are 
derived from the safety case where the user is required to perform some action to insure a safe 
process. 


Table 6-5.1 Safety Manual Requirements 


User Manual Requirements 
SRSS5O The safety manual shall contain a user instruction requiring the 
user to completely test a device’s operation before setting the Lock 
Attribute 
SRS51 The safety manual shall contain a user instruction requiring the 
user to upload and compare the configuration from each affected safety 
devices to that which was sent by the SNCT before setting the Lock 
Attribute in those devices. 
SRS52 The safety manual shall contain a user instruction requiring the 
user to clear any pre-existing configuration from any safety device before 
installing it onto a safety network. 
SRS53 The safety manual shall contain a user instruction requiring the 
user to commission all safety devices with Macld (and Baud Rate if 
necessary) prior to installing it onto a safety network 
SRS193 The Safety manual shall contain a user warning advising that 
originators that have an “automatic” SNN setting feature should only use 
that feature when the safety system is not being relied upon. 
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6-6 Safety Discrete I/O Device 
Device Type: 23nex 


A Safety Discrete I/O Device type interfaces to multiple Safety I/O device types that do not 
have network capabilities. Examples include Safety sensors and actuators 


6-6.1 Object Model 


The Object Model in Figure 6-6.1 represents a Safety Discrete I/O Device. The Table below 
includes: 


e the object classes present in this device 
e whether or not the class is required 
e the number of instances present in each class 


Table 6-6.1 Objects Present in a Safety Discrete I/O Device 


Object Class Option/Required # of Instances 

Identity Required 1 
Message Router Required 1 
Link Specific Object (s) Required 1 
DeviceNet Required for DeviceNet 1 

Safety 
Connection Control Required # 
Connection Required for DeviceNet 1 

Safety 
Safety Validator Required # 
Safety Supervisor Required 1 
Assembly Required ue 
Discrete Input Point (DIP) ee * 
Safety Discrete Input Point (SDIP) * 
Discrete Output Point (DOP) ‘hire * 
Safety Discrete Output Point (SDOP) AEE > 
Safety Dual Channel Output (SDCO) Ht bs 
Discrete Input Group (DIG) Optional 1 
Safety Discrete Input Group (SDIG) Optional 1 
Discrete Output Group (DOG) Optional 1 
Safety Discrete Output Group (SDOG) Optional 1 
* = # of instances depends on the level of I/O support provided by the product. 
vig = Optional for Standard Input Functions (provides backward compatibility) 
#ee = Optional for Standard Output Functions 
wee = Required for Safety Input Functions 
weeks = Required for Safety Output Functions 
# = Depends on the level of communications support provided by the product. 
Ht = Required for Safety Output Dual Channel Functions 

—~6-6— 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23Hex 


Figure 6-6.1 Object Model for Safety Discrete I/O Device 
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6-6.2.1 


Safety Discrete I/O Device, Type: 23 Hex 


How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Table 6-6.2 Object Affect on Behavior 


Object 


Effect on Behavior 


Identity 


No effect 


Message Router 


No effect 


Link Specific Object 


Configures communication link attributes 


Connection Control Object 


Contains the logical ports into and out of the device 


Assembly 


Defined I/O data format and configuration data format 


Safety Supervisor 


Implements the Safety Network Configuration Tool Interface 


Safety Validator 


Handles safety protocol 


Discrete Input Point (DIP) 


Defines behavior of the discrete standard input points for this 
device 


Safety Discrete Input Point 
(SDIP) 


Defines behavior of the discrete safety input points for this 
device 


Discrete Output Point (DOP) 


Defines behavior of the discrete standard output points for this 
device 


Safety Discrete Output Point 
(SDOP) 


Defines behavior of the discrete safety output points for this 
device 


Safety Dual Channel Output 


Defines behavior of the dual channel discrete safety outputs 
for this device 


Discrete Input Group 


Stores the combined status of the Discrete Input Points 


Safety Discrete Input Group 


Stores the combined status of the Discrete Safety Input Points 


Discrete Output Group 


Stores the combined status of the Discrete Output Points 


Safety Discrete Output Group 


Stores the combined status of the Discrete Safety Output 
Points 


Safety Supervisor Requirements 


The safety supervisor definition contains a number of “profile dependent” functions. This 
section defines what the required behavior shall be for the Safety Discrete I/O device profile. 


Table 6-6.3 Safety Supervisor Implementation Level 


Implementation Level 


Profile Requirement 


Baseline functionality Required 
SNCT functionality Optional 
at Ee 
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Table 6-6.4 Safety Supervisor Profile-dependent State Event Behavior 


Event “IDLE” State “Executing” State Comments 
Behavior Behavior 
Safety Connection Remain in Tf any standard or safety In this profile, device is in 
Failed/Closed IDLE T/O connection still open, | IDLE unless at least one 


remain in EXECUTING, | standard or Safety I/O 
Else, connection is established 
Transition to IDLE 


Standard or Safety I/O. 
Connection established 


Transition to 
EXECUTING state 


Remain in EXECUTING 


Type 1 SafetyOpen 


Configure device, 
transition to 


Drop standard and safety 
W/O connectior 


EXECUTING configure device, return 
to EXECUTING 
Safety I/O Connection Not supported Not supported Connection deletion not 
Deleted supported 
Mode Change Error response: Error response: No mode change defined for 
”Service Not ”Service Not Supported” | this profile 
Supported” 


Defining Object Interfaces 


The objects in this device have the interfaces listed in the following table. 


Table 6-6.5 Object Interfaces 


Object 


Interface 


Identity 


Message Router 


Message Router 


Explicit Messaging Connection Instance 


DeviceNet Message Router 
Connection Message Router 
Assembly 1/O Connection (for standard connections) or Safety Validator 


(for Safety I/O connections) or Message Router 


Safety Supervisor 


Message Router 


Safety Validator 


Message Router or Safety I/O Connection 


Discrete Input Point (DIP) 


Message Router 


Safety Discrete Input Point 
(SDIP) 


Message Router or Assembly Object 


Discrete Output Point (DOP) 


Message Router or Assembly Object 


Safety Discrete Output Point 
(SDOP) 


Message Router or Assembly Object 


Safety Dual Channel Output 


Message Router or Assembly Object 


Discrete Input Group 


Message Router 


Safety Discrete Input Group 


Message Router 


Discrete Output Group 


Message Router 


Safety Discrete Output Group 


Message Router 
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6-6.6 
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Relationship between DIP and SDIP 


A module using the Safety Discrete I/O profile may support either the SDIP, DIP, or both. An 
instance of the SDIP can be used to access inputs via safety evaluated data, or to access inputs 
as standard inputs without safety evaluation, or to access both. An Instance of the DIP can be 
used as standard discrete input data which is equivalent to the SDIP standard input data without 
safety evaluation. 


Relationship between DOP and SDOP 
A module using the Safety Discrete I/O profile may support either the SDOP, DOP, or both. 
The DOP may be used for standard Output functions or for Test Output functions. 


V/O Assembly Instances 


The I/O Assemblies for the Safety Discrete I/O Device may be classified into the following 
types. 


Table 6-6.6 I/O Assembly Object Instances for the Safety Discrete I/O Device 


Input or Output Data Type 
Input Standard Data Only 
Input Safety Data Only 
Input Safety and Standard Data 
Output Standard Data Only 
Output Safety Data Only 
Output Safety and Standard Data 


The assembly instance definition will differentiate safety data from standard data. 


When an input assembly can be accessed by both a Safety I/O connection and/or a Standard I/O 
connection, the same instance number will be used by either I/O connection type. 


When an output assembly can be accessed by a Safety I/O connection or a Standard I/O 
connection, the same instance number will be used by either of the I/O connection types. Only 
one I/O connection can be made to an output assembly at any given time. 


Where ever possible the Standard Data only assemblies that are mapped to the DIP, and DOP 
objects will use the definition in the General Purpose Discrete I/O Profile (Device Type = 
O7hex)- In addition this profile will define Standard Data only assemblies that are mapped to the 
SDIP that provide comparable functionality, but don’t require the support of or the additional 
configuration of the DIP. These assemblies will be defined in the 180-1FF),x instance range. 


NOTE: The Standard I/O assemblies defined in this device type have bits designated as 
“Reserved” within these I/O assemblies. These bits are defined as “reserved for internal use”. 
The reserved bits within the I/O assemblies may be used for module specific internal purposes. 
An example of these would be diagnostics. The reserved bits should not be assumed to be zero 
on input assemblies. 
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As denoted in the table below instance number ranges 01-63hex and 100-17F hex of this profile 
will refer to the General Purpose Discrete I/O Profile. Those assembly definitions and mapping 
will not be repeated in this profile. 


Table 6-6.7 Instance Number Ranges 


Instance Assembly Instance ID Profile that defines | Typical Uses 
Range from Assembly the Assembly 
R: Nt Data T 
eg? Object Table 6.4 Qty Sees Instance 

01-63hex Open (static assemblies 99 Standard Data General Purpose DIP or DOP 
defined in device profile) Only Discrete VO (O7jex) | based I/O data 

64-CT hex Vendor Specific static 100 Vendor Specific | Vendor Specific DIP or DOP 
assemblies and dynamic based I/O data 
assemblies 


C8-FFhex Reserved by CIP for future 56 - - 
use 


100-17 Fhex Open (static assemblies 128 Standard Data General Purpose DIP or DOP 
defined in device profile) Only Discrete /O (O7hex)_ | based I/O data 
180-1 FFyex Open (static assemblies 128 Standard Data Safety Discrete I/O SDIP or SDOP 
defined in device profile) Only (this profile) based standard 
1/O data 
200-27 Fhex Open (static assemblies 128 Safety Data Safety Discrete I/O SDIP or SDOP. 
defined in device profile) Only (this profile) based safety 
1/O data 
280-2FFhex Open (static assemblies 128 Safety and Safety Discrete I/O SDIP or SDOP 
defined in device profile) Standard Data (this profile) based safety 
and standard 
T/O data 
300-4FFhex Vendor Specific static 12 Vendor Specific | Vendor Specific 
assemblies and dynamic 
assemblies 
500-FFFF x | Reserved by CIP for future | 64,256 | - - 
use 


As denoted in the table above instance number range 180-2FF)¢x will be defined in this profile. 


The following Safety I/O assemblies 201-299,,.x are intended to line up with the Device Type 
O7hex assemblies 01-99 4c, but the radix is different. In general the 2x0-2x9}-x values will align 
with the x1-x9g.- values. The 2xA-2xF 4x assemblies are available for new definition. The 
Device Type 07, assemblies 7, 17, 27, 37, 47 and 57, that define N points are not supported by 
the 2x7hex Safety I/O assemblies. Since the N value is not contained in the safety forward open, 
these assembly definitions are ambiguous. 


This device type uses the term Combined Status in place of the term Single Status used in 
Device Type 07nex. Combined Status is used because Single Status led to confusion whether it 
meant single status bit or status for a single point. This device type also uses the term 
Individual Status in place of the term Multiple Status used in Device Type O7hex. Individual 
Status is used because Multiple Status led to confusion whether it meant multiple status bits or 
status for multiple points. 
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Standard Data Only Open Assemblies 


The following standard data only assemblies will be defined to access the Safety I/O points as 
standard I/O points without having to support the DIP object. The Standard Input(n) data in 
these assemblies maps to the Standard Input Value attribute of the SDIP, as opposed to the 
Safety Input Logical Value attribute being mapped to the assemblies including Safety Input(n) 
data. The Standard Input() data in these assemblies will be equivalent to the Discrete Input(n) 
data that is defined in the General Purpose Discrete I/O (07nex) device type. The Discrete 
Input(n) data maps to the Value attribute of the DIP. 


Table 6-6.8 Standard Data Only Open Assembly Instances 


Standard Inputs 

Instance Type Standard Input(n) 
Number 

18 Ibex In 1 

182hex In 2 

183 hex In 4 

184hex In 8 

185 hex In 16 

186 hex In 32 

18Anex In 6 

18Bhex In 10 

18Chex In 12 

18D hex In 14 
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6-6.6.2 Safety Data Only Open Assemblies 


Table 6-6.9 Safety Data Only Open Assembly Instances 


Safety Data 
Safety /O Combined Individual 
Status Status 

Instance | Type Safety Input | Safety Input Status |__ Safety Input 
Number (n) (n) Status 
201 nex In 1 

202 nex In 2 

203 nex In 4 

204 nex In 8 

205hex | _In 16 

206nex. In 32 

20Anex In 6 

20Bnex In 10 

20Chex | _In 12 

20D nex In 14 

2h In 1 Yes 

212nex In 2 Yes 

213 hex In 4 Yes 

214 nex In 8 Yes 

FAL In 16 Yes 

216hex In 32. Yes 

21Anex In 6 Yes 

21Bhex In 10 Yes 

21CG.. In 12 Yes 

21Djex | _In 14 Yes 

221 hex In 1 1 
222hex | In 2 2 
223nex_| In 4 4 
224 nex In 8 8 
225hex In 16 16 
226hex | In 32 32 
22Anex In 6 6 
22Bnex In 10 10 
22Chex In 12 12 
22Diex_| In 14 14 
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Table 6-6.10 Safety Data Only Open Assembly Instances 


Safety Data 
Safety /O Combined Status Individual Status 
Tnstance Type | Safety Safety | Safety Input | Safety Output | Safety Safety 
Number Inputin) Output(n) Status Status Tnput(n) Output(n) 
Status Status 
231 hex Out : 1 
232hex Out : 2 
233hex Out Zi 4 
234nex Out =. 8 
235pex Out : 16 
23 6hex Out - 32 
23Anex Out z 6 
23Bhex Out : 10 
23Chex Out : 12 
23Dhex Out - 14 
Al nex In = 1 
242nex In - 2 
243 hex In g 4 
244 nex In - 8 
245 nex In : 16 
246hex In : 32 
24 Avex In a 6 
24Bnex In S 10 
24Crex In : 12 
24D hex In : 14 
252hex In 2 bi Yes Yes 
253 hex In 4 * Yes Yes 
254nex In 8 * Yes Yes 
255hex In 16 is} Yes Yes 
256nex In 32 bs Yes Yes 
25Anex In 6 i Yes Yes 
25Bhex In 10 * Yes Yes 
25Chex In 12 f Yes Yes 
25D hex In 14 - Yes Yes 
262hex In 2; 2 2 
263 hex In 4 4 4 
264 nex In 8 8 8 
26 5x In 16 16 16 
26Anex In 6 6 6 
26Bnex In 10 10 10 
26Ciex In 12 12 12 
26Dhex In 14 14 14 
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Table 6-6.11 Safety Data Only Open Assembly Instances 


Safety Data 
Safety /O Combined Individual 
Status Status 

Instance Type | Safety Input(n) Safety Input | Safety Output(n) 
Number Status Status 
270 nex In 1 Yes i 

27h In a Yes 1 

272nex In 2 Yes 2 

ZPBhex In 4 Yes 2 

274 nex In 4 Yes 4 

275 nex In 8 Yes 4 
276nex In 8 Yes 8 

27 rex In 16 Yes 8 
278hex In 16 Yes 16 
27Abex In 6 Ves ¥) 
27Bhex In 10 Yes 4 
21g In 12 Yes 4 

27D hex In 14 Yes 4 


6-6.6.3 Safety Data and Standard Data Open Assemblies 


Table 6-6.12 Safety Data & Standard Data Open Assembly Instances 


Safety Data Standard Data 
Safety /0 Standard Individual Safety 
Inputs Output Monitor 
Instance Type Safety Input Standard Input(n) Safety Output(n) 
Number (n) Monitor 
281 hex In 1 i 
282hex In 2 2 
283 hex In 4 4 
284 hex In 8 8 
285 nex In 16 16 
286 nex In 32 32 
28Anex In 6 6 
28Bhex In 10 10 
28Chex In 12 12 
28D hex In 14 14 
291 icx In H T 
292nex In 2 2 
293 hex In 4 4 
294 hex In 8 8 
295 nex In 16 16 
296 hex In 32 32 
29Anex In 6 6 
29Bhex In 10 10 
29Chex In 12 12 
29D hex In 14 14 
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Table 6-6.13 Safety Data & Standard Data Only Open Assembly Instances 


Safety Data Standard Data 
Safety /O Combined Individual Status Individual Safety | Standard 
Status Output Monitor | Outputs 
Instance | Type Safety Safety Safety Input Safety Safety Safety Output(n) | Standard 
Number Input(n) |_Output(n) Status | Input(n) Status| Output(n) Status Monitor Output(n) 
2A hex In 1 Yes 1 
ZA2nex | _In 2 Yes 2 
2A3hex In 4 Yes 4 
2MAnex In 8 Yes 8 
2ASnex In 16 Yes 16 
2AGrex | _In 32 Yes 32 
2AAnex In 6 Yes 6 
2ABnex In 10 Yes 10 
2AChex_|__In 12 Yes 12 
2ADhex_| _In 14 Yes 14 
2Blhox In 1 1 1 1 
2B2hex | __In 2 2 2 2 
2B3 nex In 4 4 4 4 
2B4 nex In 8 8 8 8 
2BS5icx_| In 16 16 16 16 
2B6yex_|_In 32 32 32 32 
2BAnex In 6 6 6 6 
2BBrex In 10 10 10 10 
2BCyex | __In 12 12 12 12 
2BDyex_|__In 14 14 14 14 
2CThex | Out 1 I 
2C2rex Out 2 2 
2C3nex_| Out 4 4 
2C4 nex | Out 8 8 
2C5rex_| Out 16 16 
2COyex_| Out 32 32 
2CArex_| Out 6 6 
2CByex | Out 10 10 
2CCrex_| Out 12 12 
2CDyex_| Out 14 14 
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6-6.7.1 


Safety Discrete I/O Device, Type: 23 Hex 


1/O Assembly Data Attribute Format 


Standard Data Only Open Assemblies 


The following standard 


Safety Input Logical Value attribute being mapped to the assem! 


data only assemblies will be defined to access the Safety I/O points as 
standard I/O points without having to support the DIP object. The Standard Input(n) data in 
these assemblies maps to the Standard Input Value attribute of the SDIP, as opposed to the 


blies that include Safety 


Input(7) data. The Standard Input(7) data in these assemblies will be equivalent to the Discrete 
ined in the General Purpose Discrete I/O (O7pex) device type. The 


Input(n) data that is de 


Discrete Input(n) data maps to the Value attribute of the DIP. 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bit 
181 hex 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Standard 
Input 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
182hex 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Standard | Standard 
Input2 Input! 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bit 
183 hex 0 Reserved | Reserved | Reserved | Reserved | Standard | Standard | Standard | Standard 
Input4 Input3 Input2 Input1 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bit 
184 0 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Input1 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
185 hex 0 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Tnput8 Tnput7 Tnput6 Tnput5 Tnput4 Tnput3 Tnput2 Input! 
1 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Tnputl6 Input!5 Inputl4 Inputl3 Input!2 Input! 1 Inputl0 Input9 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
186 hex 0 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Input8 Input7 Input6 Input Input4 Input3 Input2 Input! 
1 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Inputl6 InputlS Inputl4 Input13 Input12 Inputl1 Inputl0 Input9 
2 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Input24 Input23 Input22 Input21 Input20 Inputl9 Input18 Inputl7 
3) Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Input32 Input31 Input30 Input29 Input28 Input27 Input26 Input25 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
18Ahex 0 Reserved | Reserved | Standard | Standard | Standard | Standard | Standard | Standard 
Tnput6 Tnput5 Input4 Input3 Input2 Input! 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
18Bhex 0 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Input Input7 Input6 InputS Input4 Input3 Input2 Inputl 

1 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Standard | Standard 

Input!0 | Input9 

Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
18Chex 0 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Input8 | Input? | Inputo | Inputs | Input4 | Input3 | Input2 | Inputl 

1 Reserved | Reserved | Reserved | Reserved | Standard | Standard | Standard | Standard 

Inputl2 | Inputtt | InputlO | Inputd 

Instance | Byte Bit7 Bité Bit5 Bit4 Bit3 Bit2 Bitl BitO 
18Dhex 0 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Input Input7 Input6 Input Input4 Input3 Input2 Input! 
1 Reserved | Reserved | Standard | Standard | Standard | Standard | Standard | Standard 

Inputl4 Input13 Input12 Inputl1 Input 10 Input9 

6-6.7.2 Safety Data Only Open Assemblies 

Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bit 
201 hex 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Safety 
Input1 

Instance | Byte Bit7 Bit Bit5 Bit4 Bit3 Bit2 Bitl Bito 
202hex 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Input2 Input! 

Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
203 hex 0 Reserved | Reserved | Reserved | Reserved | Safety Safety Safety Safety 
Input4 Input3 Input2 Input! 

Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
204 hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input’ Input7 Input6 InputS Input4 Input3 Input2 Input! 

Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
205hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Tnput8 Tnput7 Tnput6 Tnput5 Tnput4 Tnput3 Input2 Input! 

i Safety Safety Safety Safety Safety Safety Safety Safety 

Inputl6 | Inputl5 | Inputi4 | Inputi3 | Iputi2 | Inputil | InputloO | Inputd 

Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
206 hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input Input4 Input3 Input2 Input! 

il Safety Safety Safety Safety Safety Safety Safety Safety 

Inputl6 Input15 Inputl4 Inputl3 Input12 Input! 1 Input10 Input9 

pe Safety Safety Safety Safety Safety Safety Safety Safety 

Input24 Input23 Input22 Input21 Input20 Input 19 Input18 Input17 

3 Safety Safety Safety Safety Safety Safety Safety Safety 

Input32 Input31 Input30 Input29 Input28 Input27 Input26 Input25 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
20Anex 0 Reserved | Reserved Safety Safety Safety Safety Safety Safety 
Input6 Input Input4 Input3 Input2 Input! 
Instance | Byte Bit7 Bit6é Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
20Bnex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Tnput8 Input7 Input6 Input5 Input4 Input3 Input2 Input] 
1 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
InputlO | Inputd 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
20Chex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Inputl 
il Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Input12 Inputl1 Input 10 Input9 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
20Dhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 | Input? | Inputé | Inputs | Input4 | Input3 | Input2 | Inputl 
1 Reserved | Reserved Safety Safety Safety Safety Safety Safety 
Inputl4 | Inputl3 | Inputl2 | Inputtt | IputlO | Inputd 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
Zilles 0 Safety | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Safety 
Input Input! 

Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
Sos, 0 Safety Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Input Tnput2 Input 

Status 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
Bier 0 Safety Reserved | Reserved | Reserved Safety Safety Safety Safety 
Input Input4 Input3 Input2 Input! 

Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
214hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Tnput8 Tnput7 Tnput6 Tnput5 Tnput4 Tnput3 Tnput2 Input! 
1 Safety Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 

Input 

Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
DSi 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input Input7 Input6 Input Input4 Input3 Input2 Input! 
i Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 Inputl5 Inputl4 Input13 Input12 Input! 1 InputlO Input9 
2 Safety Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 

Input 

Status 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
216 hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Inputl 
i Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | InputiS | Inputi4 | Inputi3 | Inputi2 | Inputit | InputloO | Input9 
2) Safety Safety Safety Safety Safety Safety Safety Safety 
Input24 Input23 Input22 Input21 Input20 Inputl9 Inputl8 Input17 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Input32 Input31 Input30 Input29 Input28 Input27 Input26 Input25 
4 Safety | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 

Input 

Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
21Ahex 0 Safety Reserved Safety Safety Safety Safety Safety Safety 
Input Tnput6 Tnput5 Tnput4 Tnput3 Tnput2 Input! 

Status 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
21Bhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Input1 
1 Safety | Reserved | Reserved | Reserved | Reserved | Reserved | Safety Safety 
Input Input 10 Input9 

Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
21Chex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Tnput7 Tnput6 TInput5 Input4 Input3 Input2 Input! 
1 Safety Reserved | Reserved | Reserved Safety Safety Safety Safety 
Input Input12 Input11 Input10 Tnput9 

Status 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
21Dtex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input’ Input7 Input6 Input Input4 Input3 Input2 Inputl 
‘il Safety Reserved Safety Safety Safety Safety Safety Safety 
Input Inputl4 Input13 Input12 Input!1 Inputl0 Input9 

Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
PRA, 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Input Input 

Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
222i 0 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Input2 Input Input2 Input1 
Status Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
ean 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Tnput4 Tnput3 Input2 Input] Input4 Input3 Input2 Input! 
Status Status Status Status 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
22A}ex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Inputl 
i Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bité Bit5 Bit4 Bit3 Bit2 Bitl Bito 
DS 0 Safety Safety Safety Safety | Safety Safety Safety | Safety 
Tnput8 Input7 Tnput6 Tnput5 Input4 Input3 Input2 Input! 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputi5 | Inputi4 | Inputi3 | Iputi2 | Inputil | InputloO | Inputd 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Tnput8 Input7 Tnput6 Tnput5 Input4 Input3 Tnput2 Tnputl 
Status Status Status Status Status Status Status Status 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputls | Inputi4 | Inputi3 | Inputi2 | Inputil | InputlO | Inputd 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
226 tex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input Input7 Input6 InputS Input4 Input3 Input2 Inputl 
il Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 Inputl5 Inputl4 Inputl3 Inputl2 Input 1 Inputl0 Input9 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Input24 Input23 Input22 Input21 Input20 Inputl9 Inputl8 Input17 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Input32 Input31 Input30 Input29 Input28 Input27 Input26 Input25 
4 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input Input4 Input3 Input2 Input 
Status Status Status Status Status Status Status Status 
5 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 Inputl5 Inputl4 Input13 Inputl2 Input 1 Inputl0 Input9 
Status Status Status Status Status Status Status Status 
6 Safety Safety Safety Safety Safety Safety Safety Safety 
Input24 Input23 Input22 Input21 Input20 Inputl9 Inputl8 Input17 
Status Status Status Status Status Status Status Status 
eh Safety Safety Safety Safety Safety Safety Safety Safety 
Input32 Input31 Input30 Input29 Input28 Input27 Input26 Input25 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
Doral Safety Safety Safety Safety | Safety Safety Safety | Safety 
Tnput2 Input! Tnput6 Tnput5 Input4 Tnput3 Tnput2 Input! 
Status Status 
1 | Reserved | Reserved | Reserved | Reserved | Safety Safety Safety | Safety 
Input6 Input5 Tnput4 Tnput3 
Status Status Status Status 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
22Bhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Inputl 
i Safety Safety Safety Safety Safety Safety Safety Safety 
Input6 Input5 Input4 Input3 Input2 Input! Inputl0 | Input9 
Status Status Status Status Status Status 
2 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
InputlO Input9 Input8 Input7 
Status Status Status Status 
Instance | Byte Bit7 Bit BitS Bit4 Bit3 Bit2 Bitl Bito 
22Chex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Tnput3 Input2 Input 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Tnput4 Tnput3 Input2 Input Input 12 Input! 1 Inputl0 Tnput9 
Status Status Status Status 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
TInput12 Input! 1 Tnputl0 Tnput9 Input Tnput7 Tnput6 TnputS 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
22Dhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input’ Input7 Input6 Input Input4 Input3 Input2 Input! 
il Safety Safety Safety Safety Safety Safety Safety Safety 
Input2 Inputl Inputl4 Inputl3 Inputl2 Inputl1 Inputl0 Input9 
Status Status 
2} Safety Safety Safety Safety Safety Safety Safety Safety 
Input 10 Input9 Input8 Input7 Input6 InputS Input4 Input3 
Status Status Status Status Status Status Status Status 
2} Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Inputl4 Input13 Input12 Inputl1 
Status Status Status Status 
Instance | Byte Bit7 Bit Bit5 Bit4 Bit3 Bit2 Bitl Bito 
Boilrer 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Safety 
Output1 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
Dayle 0 | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Safety Safety 
Output2 | Output! 
Instance | Byte Bit7 Bit BitS Bit4 Bit3 Bit2 Bitl Bito 
233 nex 0 | Reserved | Reserved | Reserved | Reserved | Safety Safety Safety | Safety 
Output4 | Output3 | Output2 | Output! 
Instance | Byte Bit7 Bit Bit5 Bit4 Bit3 Bit2 Bitl BitO 
234nex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 Output7 Output6 OutputS Output4 Output3 Output2 | Output! 
Instance | Byte Bit7 Bit6é BitS Bit4 Bit3 Bit2 Bitl Bitd 
Bearer 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output? | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl6 | Output!S | Outputl4 | Outputl3 | Outputl2 | Outputl! | OutputlO | Output9 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
236hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 Output7 Output6 OutputS Output4 Output3 Output2 | Output! 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl6 | Outputs | Outputi4 | Output!3 | Outputi2 | Outputi1 | Outputlo | Output9 
oy Safety Safety Safety Safety Safety Safety Safety Safety 
Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Outputl8 | Outputl7 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Output32 | Output31 | Output30 | Output29 | Output28 | Output27 | Output26 | Output25 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
23Anex 0 Reserved | Reserved Safety Safety Safety Safety Safety Safety 
Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bit 
23Bhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
iL Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Outputl0 | Output9 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
eae 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
i Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Outputl!2 | Outputl1 | OutputlO | Output9 
Instance | Byte Bit7 Bit6é BitS Bit4 Bit3 Bit2 Bitl Bito 
23Dhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output? | Output6 | OutputS | Output4 | Output3 / Output2 | Output! 
1 Reserved | Reserved | Safety Safety Safety Safety Safety Safety 
Outputl4 | Outputl3 | Output!2 | Output! 1 | OutputlO | Output9 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2Alnex 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety 
Output! 
Status 
Instance | Byte Bit7 Bit BitS Bit4 Bit3 Bit2 Bitl Bito 
242Qnex 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Safety Safety 
Output2 | Output! 
Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
243 hex 0 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Output4 | Output3 | Output2 | Output! 
Status Status Status Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
244} nex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output? | Output6 | Outputs | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
245 hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 Output7 Output6 OutputS Output4 Output3 Output2 | Output! 
Status Status Status Status Status Status Status Status 
il Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl6 | OutputlS | Outputl4 | Outputl3 | Output!2 | Outputl1 | OutputlO | Output9 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
246nex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output? | Output6 | OutputS | Output4 | Output3 ] Output2 | Output! 
Status Status Status Status Status Status Status Status 
it Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl6 | Outputl5 | Outputl4 | Output!3 | Outputl2 | Output! | OutputlO | Output9 
Status Status Status Status Status Status Status Status 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Outputl8 | Output!7 
Status Status Status Status Status Status Status Status 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Output32 | Output31 | Output30 | Output29 | Output28 | Output27 | Output26 | Output25 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
24Atex 0 Reserved | Reserved Safety Safety Safety Safety Safety Safety 
Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
24Bnex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output | Output? | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
1 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Outputl0 | Output9 
Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
24Chex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
il Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Outputl2 | Outputl1 | OutputlO | Output9 
Status Status Status Status 
Instance | Byte Bit7 Bité Bit5 Bit4 Bit3 Bit2 Bitl Bit 
24Direx 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
il Reserved | Reserved Safety Safety Safety Safety Safety Safety 
Outputl4 | Outputl3 | Outputl!2 | Output! | OutputlO | Output9 
Status Status Status Status Status Status 
Instance | Byte Bit7 Bit BitS Bit4 Bit3 Bit2 Bitl Bitd 
Dozier 0 Safety Safety Reserved | Reserved | Reserved | Reserved Safety Safety 
Input Output Input2 Input! 
Status Status 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
oShee 0 Safety Safety Reserved | Reserved Safety Safety Safety Safety 
Input Output Input4 Input3 Input2 Inputl 
Status Status 
Instance | Byte Bit7 Bit Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
254nex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Tnput3 Input2 Input 
1 Safety Safety Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 
Input Output 
Status Status 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
DSS hee 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input Input4 Input3 Input2 Inputl 
il Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 Inputl5 Inputl4 Input13 Input12 Input 1 Inputl0 Input9 
2: Safety Safety Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 
Input Output 
Status Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
256 rex 0 Safety Safety Safety Safety | Safety Safety Safety Safety 
Tnput8 Tnput7 Tnput6 Tnput5 Tnput4 Tnput3 TInput2 Input! 
il Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputi5 | Inputi4 | Inputi3 | Iputi2 | Inputii | Inputlo | Inputd 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Input24 | Input23 | Input22 | Input21 | Input20 } Inputi9 | Inputi8 | Inputl7 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Input32_ | Input31 | Input30 | Input29 | Input28 | Input27 | Input26 | Input2s 
4 Safety Safety Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 
Input Output 
Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
25Atex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input Output Input6 Input Input4 Input3 Input2 Input! 
Status Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
2oBes 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Tnput8 Input7 Tnput6 Tnput5 Tnput4 Tnput3 Tnput2 Input! 
1 Safety Safety Reserved | Reserved | Reserved | Reserved Safety Safety 
Input Output Inputl0 Tnput9 
Status Status 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
25Chex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input’ Input7 Input6 Input Input4 Input3 Input2 Input! 
1 Safety Safety | Reserved | Reserved | Safety Safety Safety Safety 
Input Output Input12 Inputl 1 Inputl0 Input9 
Status Status 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
25Dix 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Inputl 
il Safety Safety Safety Safety Safety Safety Safety Safety 
Input Output | Inputi4 | Inputi3 | Inputi2 | Inputii | Inputio | Input9 
Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
262hex 0 | Reserved | Reserved | Safety Safety | Safety Safety Safety | Safety 
Output2 | Output! Input2 Input! Input2 Input 
Status Status Status Status 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
263 hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input4 Input3 Input2 Input! Input4 Input3 Input2 Input! 
Status Status Status Status 
1 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Output4 Output3 Output2 | Output! 
Status Status Status Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
264 rex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Tnput8 Input7 Tnput6 Tnput5 Tnput4 Tnput3 Input2 Input! 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Input Input7 Input6 Input5 Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
D Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 Output7 Output6 OutputS Output4 Output3 Output2 | Output! 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
265hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input’ Input7 Input6 Input Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 InputlS Inputl4 Inputl3 Inputl2 Input! 1 Inputl0 Input9 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 Inputl5S Inputl4 Inputl3 Inputl2 Inputl1 Inputl0 Input9 
Status Status Status Status Status Status Status Status 
4 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 Output7 Output6 OutputS Output4 Output3 Output2 | Output! 
Status Status Status Status Status Status Status Status 
5) Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl! | OutputlO | Output9 
Status Status Status Status Status Status Status Status 
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Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23 Hex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
26Arex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input2 Inputl Input6 InputS Input4 Input3 Input2 Input! 
Status Status 
il Safety Safety Safety Safety Safety Safety Safety Safety 
Output4 Output3 Output2 Output! Input6 InputS Input4 Input3 
Status Status Status Status Status Status Status Status 
2 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Output4 | Output3 | Output6 | Outputs 
Status Status Status Status 
Instance | Byte Bit7 Bité Bit5 Bit4 Bit3 Bit2 Bitl Bito 
26Brex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input! 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Tnput6 TnputS Input4 TInput3 Input2 Input! Tnputl0 Tnput9 
Status Status Status Status Status Status 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Output4 | Output3 | Output2 | Output! | InputlO Input9 Input Input7 
Status Status Status Status Status Status Status Status 
3 Reserved | Reserved | Safety Safety Safety Safety Safety Safety 
Outputl0 | Output9 | Output8 | Output7 | Output6 | Outputs 
Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
26Chex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Input! 
ih Safety Safety Safety Safety Safety Safety Safety Safety 
Input4 Tnput3 Input2 Input Inputl2 Input! 1 Inputl0 Input9 
Status Status Status Status 
oy Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl2 Input! 1 InputlO Input9 Input Input7 Input6 InputS 
Status Status Status Status Status Status Status Status 
3} Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
4 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Outputl0 | Output9 
Status Status 
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Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23 Hex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
26Dhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Input1 
i Safety Safety Safety Safety Safety Safety Safety Safety 
Input2 Inputl Inputi4 | Inputi3 | Inputi2 | Inputii | InputiO | Input9 
Status Status 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl0 Input9 Input’ Input7 Input6 InputS Input4 Input3 
Status Status Status Status Status Status Status Status 
3} Safety Safety Safety Safety Safety Safety Safety Safety 
Output4 Output3 Output2 Output! Inputl4 Input13 Inputl2 Inputl1 
Status Status Status Status Status Status Status Status 
4 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl2 | Outputl1 | OutputlO | Output9 Output8 Output7 Output6 | Outputs 
Status Status Status Status Status Status Status Status 
5 | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Safety | Safety 
Outputl4 | Outputl3 
Status Status 
Instance | Byte Bit7 Bit BitS Bit4 Bit3 Bit2 Bitl Bitd 
270bex 0 Safety | Reserved | Reserved | Reserved | Reserved | Reserved | Safety Safety 
Input Output! Input! 
Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
allies 0 Safety Reserved | Reserved | Reserved | Reserved Safety Safety Safety 
Input Outputl Input2 Inputl 
Status Status 
Instance | Byte Bit7 Bit BitS Bit4 Bit3 Bit2 Bitl Bito 
ir 0 Safety | Reserved | Reserved | Reserved | Safety Safety Safety Safety 
Input Output2 | Outputl Input2 Inputl 
Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
aoe 1) Safety Reserved Safety Safety Safety Safety Safety Safety 
Input Output2 | Output! Input4 Input3 Input2 Input! 
Status Status Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
274nex 0 Safety | Reserved | Reserved | Reserved | Safety Safety Safety Safety 
Input Input4 Input3 Input2 Input! 
Status 
1 Reserved | Reserved | Reserved | Reserved | Safety Safety Safety Safety 
Output4 | Output3 | Output2 | Output! 
Status Status Status Status 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
Pais 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input Input7 Input6 Input Input4 Input3 Input2 Inputl 
il Safety Reserved | Reserved | Reserved Safety Safety Safety Safety 
Input Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status 
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Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23 Hex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
276 hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Inputl 
1 Safety Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 
Input 
Status 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 Output7 Output6 OutputS Output4 Output3 Output2 | Output! 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bité BitS Bit4 Bit3 Bit2 Bitl Bito 
liter 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputis | Inputi4 | Inputi3 | Inputi2 | Inputil | InputlO | Inputd 
D Safety | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 
Input 
Status 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output? | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
278 hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input’ Input7 Input6 Input Input4 Input3 Input2 Inputl 
ik Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 InputlS Inputl4 Input13 Inputl2 Input! 1 Inputl0 Tnput9 
2 Safety Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 
Input 
Status 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
4 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl1 | OutputlO | Output9 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
27A nex 0 Safety | Reserved | Safety Safety Safety Safety Safety Safety 
Input Tnput6 Tnput5S Tnput4 Input3 Tnput2 Input 
Status 
iL Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Output2 | Output! 
Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
27Bhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input Input4 Input3 Input2 Input! 
i Safety Reserved Safety Safety Safety Safety Safety Safety 
Input Output4 Output3 Output2 Output! Inputl0 Input9 
Status Status Status Status Status 
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Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23 Hex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
BiG 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input Input4 Input3 Input2 Inputl 
i Safety Reserved | Reserved | Reserved Safety Safety Safety Safety 
Input Inputi2 | Inputil | InputiO | Input9 
Status 
2 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Output4 Output3 Output2 | Output! 
Status Status Status Status 
Instance | Byte Bit7 Bit6é BitS Bit4 Bit3 Bit2 Bitl Bito 
27D ex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Tnput3 Input2 Input! 
1 Safety | Reserved | Safety Safety Safety Safety Safety Safety 
Input Inputi4 | Inputi3 | Inputi2 | Inputi! | InputiO | Inputd 
Status 
4 Reserved | Reserved | Reserved | Reserved | Safety Safety Safety Safety 
Output4 | Output3 ) Output2 | Output! 
Status Status Status Status 
6-6.7.3 Safety Data and Standard Data Open Assemblies 
Note: Safety Data is bolded 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
281 hex 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Standard Safety 
Input! Inputl 
Instance |_Byte | _ Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
282nex 0 Reserved | Reserved | Reserved | Reserved | Standard | Standard Safety Safety 
Input2 Input! Input2 Inputl 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
283 nex 0 Standard | Standard | Standard | Standard Safety Safety Safety Safety 
Input4 Input3 Input2 Input Input4 Input3 Input2 Inputl 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
284nex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Input! 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
285 rex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | InputlS | Inputi4 | Inputi3 | Inputi2| Inputll | Inputi0| Input? 
2 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Input1 
3 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Inputl6 Inputl5 Inputl4 Inputl3 Inputl2 Input 1 Inputl0 Input9 
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Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23 Hex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
286hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 

1 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputi5 | Inputi4 | Inputl3 | Inputi2 | Inputil | Inputi0 | Input9 

2; Safety Safety Safety Safety Safety Safety Safety Safety 
Input24 | Input23 | Input22 | Input21 | Input20 | Inputl9 | Inputi8 | Inputl7 

3} Safety Safety Safety Safety Safety Safety Safety Safety 
Input32 | Input31 | Input30 | Input29 | Input28 | Input27 | Input26 | Input25 
4 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 

Tnput8 Input7 Input6 Tnput5S Input4 Tnput3 Input2 Input! 
5) Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 

Inputl6 Tnputl5 Inputl4 Input13 Input12 Input! 1 Inputl0 Tnput9 
6 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 

Input24 Input23 Input22 Input21 Input20 Inputl9 Input18 Input17 
a Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 

Input32 Input31 Input30 Input29 Input28 Input27 Input26 Input25 

Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
28Anex 0 Standard | Standard Safety Safety Safety Safety Safety Safety 
Input2 Inputl Input6 Input5 Input4 Input3 Input2 Inputl 
1 Reserved | Reserved | Reserved | Reserved | Standard | Standard | Standard | Standard 

Input6 Input5 Input4 Input3 

Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
28Bhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
i Standard | Standard | Standard | Standard | Standard | Standard Safety Safety 
Input6 TnputS Input4 Input3 Input2 Input! Inputl0 Input9 
2 Reserved | Reserved | Reserved | Reserved | Standard | Standard | Standard | Standard 

Input 10 Input? Input8 Input7 

Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
28Chex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input1 
1 Standard | Standard | Standard | Standard Safety Safety Safety Safety 
Input4 Input3 Input2 Input Inputl2 | Inputl1 | Inputl0 Input® 
2 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 

Input12 Input! 1 Inputl0 Input9 Input Input7 Input6 InputS 

Instance | Byte Bit7 Bit BitS Bit4 Bit3 Bit2 Bitl Bito 
28Dhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Standard | Standard Safety Safety Safety Safety Safety Safety 
Input2 Input! Inputi4 | Inputi3 | Inputl2 | Inputl1 | Inputl0| Input9 
2 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 

Inputl0 Input9 Input’ Input7 Input6 InputS Input4 Input3 
4 Reserved | Reserved | Reserved | Reserved | Standard | Standard | Standard | Standard 

Inputl4 Input13 Input12 Inputl1 

Instance | Byte Bit7 Bit6 Bit5S Bit4 Bit3 Bit2 Bitl BitO 
Bales, 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Output] Inputl 

Monitor 
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Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23 Hex 


Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
292hex 0 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Output2 | Output! Input2 Inputl 
Monitor | Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
293 hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output4 | Output3 | Output2 | Output! Input4 Input3 Input2 | Input! 
Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
294nex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 Output7 Output6 OutputS Output4. Output3 Output2 Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
295 ex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input1 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputl5 | Inputi4 | Inputl3 | Inputi2 | Inputll | Inputi0| Input? 
2 Safety | Safety Safety Safety | Safety Safety Safety | Safety 
Output8 | Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl6 | Outputl5 | Outputl4 | Outputl3 | Output!2 | Output! 1 | Output! | Output9 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
296 hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
tt Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputl5 | Inputi4 | Inputl3 | Inputl2 | Inputll | Inputi0 | Input? 
2) Safety Safety Safety Safety Safety Safety Safety Safety 
Input24 | Input23 | Input22 | Input21 | Input20| Inputl9 | Inputi8 | Inputi7 
3h Safety Safety Safety Safety Safety Safety Safety Safety 
Input32 | Input31 | Input30 | Input29 | Input28 | Input27 | Input26 | Input25 
4 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 Output7 Output6 OutputS Output4 Output3 Output2 Output1 
Monitor | Monitor Monitor Monitor Monitor | Monitor | Monitor | Monitor 
5) Safety Safety Safety Safety Safety Safety Safety Safety 
Output!6 | Output!5 | Outputl4 | Outputl3 | Output!2 | Output! 1 | Output! | Output9 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
6 Safety Safety Safety Safety Safety Safety Safety Safety 
Output24 | Output23 | Output22 | Output21 | Output20 | Output!9 | Output!8 | Outputl7 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
7 Safety Safety Safety Safety Safety Safety Safety Safety 
Output32 | Output31 | Output30 | Output29 | Output28 | Output27 | Output26 | Output25 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
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Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23 Hex 


Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
29Atex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output2 | Output] Input6 Input5 Input4 Input3 Input2 Inputl 
Monitor | Monitor 
1 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Output6 OutputS Output4 | Output3 
Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6é Bit5 Bit4 Bit3 Bit2 Bitl BitO 
29Bhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 InputS Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Output6 | OutputS | Output4 | Output3 | Output2 | Output! Inputl0 | Input9 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
2 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
OutputlO | Output9 Output8 Output7 
Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
29Chex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Output4 | Output3 | Output2 | Output! Inputl12 | Inputl1 | Inputl0 Input® 
Monitor | Monitor | Monitor | Monitor 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl2 | Outputl1 | OutputlO | Output9 | Output8 | Output7 | Output6 | Outputs 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
29D hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Output2 Output! Inputl4 Input13 | Inputl2 Inputl1 Inputl0 Input9 
Monitor | Monitor 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl0 | Output9 | Output8 | Output7 | Output6 | OutputS | Output4 | Output3 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
2] Reserved | Reserved | Reserved | Reserved | Safety Safety Safety Safety 
Outputl4 | Outputl3 | Outputl2 | Output! 1 
Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit Bit5 Bit4 Bit3 Bit2 Bitl Bito 
Aes 0 Safety | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety 
Input Inputl 
Status 
1 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Safety 
Output 
Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2A2hex 0 Safety | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Input Input2 Inputl 
Status 
1 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Safety Safety 
Output2 | Output! 
Monitor | Monitor 
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Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23 Hex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2A3hex 0 Safety | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Input Input4 Input3 Input2 Inputl 
Status 
1 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2A4nex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 
Input 
Status 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl BitO 
2AS5tex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | InputlS | Inputi4 | Inputi3 | Inputi2 | Inputll | Inputi0| Input? 
2) Safety | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 
Input 
Status 
a) Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
4 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl! | OutputlO | Output9 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2A6hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input1 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputl5 | Inputi4 | Inputl3 | Inputi2 | Inputll | Inputi0| Input? 
2. Safety Safety Safety Safety Safety Safety Safety Safety 
Input24 | Input23 | Input22 | Input21 | Input20 | Inputi9 | Inputi8 | Inputl7 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Input32 | Input31 | Input30 | Input29 | Input28 | Input27 | Input26 | Input25 
4 Safety | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved 
Input 
Status 
5 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Outputl 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
6 Safety Safety Safety Safety Safety Safety Safety Safety 
Output!6 | Outputl5 | Outputl4 | Outputl3 | Output!2 | Output! 1 | Output!O | Output9 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
a Safety Safety Safety Safety Safety Safety Safety Safety 
Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Output!8 | Outputl7 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
8 Safety Safety Safety Safety Safety Safety Safety Safety 
Output32 | Output31 | Output30 | Output29 | Output28 | Output27 | Output26 | Output25 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
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Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23 Hex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2AA tex 0 Safety | Reserved | Safety Safety Safety Safety Safety Safety 
Input Input6 Input5 Input4 Input3 Input2 Inputl 
Status 
1 Reserved | Reserved Safety Safety Safety Safety Safety Safety 
Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2ABhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input1 
1 Safety | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Input Inputl0 Input9 
Status 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
3 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Safety Safety 
Outputl0 | Output9 
Monitor | Monitor 
Instance | Byte Bit7 Bit BitS Bit4 Bit3 Bit2 Bitl Bito 
2AChex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety | Reserved | Reserved | Reserved | Safety Safety Safety Safety 
Input Input12 | Inputl1 Inputl0 Input9 
Status 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 Output7 Output6 Output5S Output4 Output3 Output2 Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
3} Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Outputl2 | Outputl! | OutputlO | Output? 
Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
2ADhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety | Reserved Safety Safety Safety Safety Safety Safety 
Input Inputl4 | Inputl3 | Inputi2 |} Inputi1 | Inputl0 Input9 
Status 
2D Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output? | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
a} Reserved | Reserved Safety Safety Safety Safety Safety Safety 
Outputl4 | Output!3 | Outputl2 | Outputl! | OutputlO | Output9 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2B hex 0 Reserved | Reserved | Reserved | Reserved | Safety Safety Safety Safety 
Output! Outputl Input1 Inputl 
Monitor Status Status 
Instance | Byte Bit7 Bit6 Bits Bit4 Bit3 Bit2 Bitl Bit0 
2B2bex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output2 | Output! Output2 |} Outputl| Input2 Inputl Input2 Inputl 
Monitor | Monitor Status Status Status Status 
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Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Discrete I/O Device, Type: 23 Hex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2B3hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input4 Input3 Input2 Inputl Input4 Input3 Input2 Inputl 
Status Status Status Status 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Output4 | Output3 | Output2 | Output! Output4 | Output3) Output2| Outputl 
Monitor | Monitor | Monitor | Monitor Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2B4nex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input1 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
Status Status Status Status Status Status Status Status 
2; Safety Safety Safety Safety Safety Safety Safety Safety 
Output8| Output7 | Output6| OutputS| Output4} Output3 | Output2| Outputl 
Status Status Status Status Status Status Status Status 
BI Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 Output7 Output6 OutputS Output4 Output3 Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit BitS Bit4 Bit3 Bit2 Bitl Bito 
2BShex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputi5 | Inputi4 | Inputi3 | Inputi2 | Inputil | Inputi0 | Input9 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
Status Status Status Status Status Status Status Status 
3 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputi5 | Inputi4| Inputl3 | Inputi2 | Inputil | Inputld Input9 
Status Status Status Status Status Status Status Status 
4 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8| Output7 | Output6| OutputS | Output4} Output3| Output2) Outputl 
Status Status Status Status Status Status Status Status 
5 Safety Safety Safety Safety Safety Safety Safety Safety 
Output16| Outputl5| Outputl4| Outputl13) Outputl2) Outputi1} Outputl0); Output9 
Status Status Status Status Status Status Status Status 
6 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
7 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl1 | OutputlO | Output9 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 

2B6nex 0 Safety Safety Safety Safety Safety Safety Safety Safety 

Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 

1 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputi5 | Inputi4 | Inputl3 | Inputi2 | Inputil | Inputi0 | Input9 

2; Safety Safety Safety Safety Safety Safety Safety Safety 
Input24 | Input23 | Input22 | Input21 | Input20 | Inputl9 | Inputi8 | Inputl7 

3 Safety Safety Safety Safety Safety Safety Safety Safety 
Input32 | Input31 | Input30 | Input29 | Input28 | Input27 | Input26 | Input25 

4 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 

Status Status Status Status Status Status Status Status 

5 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl6 | Inputi5 | Inputi4| Inputl3 | Inputi2 | Inputil | Inputld Tnput9 

Status Status Status Status Status Status Status Status 

6 Safety Safety Safety Safety Safety Safety Safety Safety 
Input24 | Input23 | Input22| Input21 | Input20| Inputl9 | Inputi8| Inputi7 

Status Status Status Status Status Status Status Status 

af Safety Safety Safety Safety Safety Safety Safety Safety 
Input32 | Input31 | Input30 | Input29 | Input28 | Input27 | Input26| Input25 

Status Status Status Status Status Status Status Status 

8 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8| Output7 | Output6| OutputS| Output4} Output3| Output2) Outputl 

Status Status Status Status Status Status Status Status 

9 Safety Safety Safety Safety Safety Safety Safety Safety 
Output16| Output15| Outputl4| Output13) Outputl2) Outputil| Outputl0); Output9 
Status Status Status Status Status Status Status Status 

10 Safety Safety Safety Safety Safety Safety Safety Safety 
Output24| Output23) Output22) Output21) Output20/ Outputl9| Outputl8) Outputl 
Status | Status | Status | Status | Status | Status | Status | Status _ 

i Safety Safety Safety Safety Safety Safety Safety Safety 
Output32) Output31) Output30} Output29| Output28) Output27| Output26) Output25 
Status Status Status Status Status Status Status Status 

12 Safety Safety Safety Safety Safety Safety Safety Safety 

Output8 | Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 

13 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl6 | Outputl5 | Outputl4 | Outputl3 | Outputl!2 | Output! 1 | Outputl0 | Outputd 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 

14 Safety Safety Safety Safety Safety Safety Safety Safety 
Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Output!8 | Outputl7 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 

iS: Safety Safety Safety Safety Safety Safety Safety Safety 
Output32 | Output31 | Output30 | Output29 | Output28 | Output27 | Output26 | Output25 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 


2BAnex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input2 Input1 Input6 Input5 Input4 Input3 Input2 Inputl 
Status Status 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Output4| Output3) Output2|} Outputl| Input6 Input5 Input4 Input3 
Status Status Status Status Status Status Status Status 
2 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Output6 | Output5 
Status Status 
3 Reserved | Reserved Safety Safety Safety Safety Safety Safety 
Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bit 
2BBnex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 


Input6 Input5 Input4 Input3 Input2 Inputl Inputl0 Input9 
Status Status Status Status Status Status 
2: Safety Safety Safety Safety Safety Safety Safety Safety 
Output4| Output3 |} Output2| Outputl| Inputld Input9 Input8 Input7 
Status Status Status Status Status Status Status Status 
5 Reserved | Reserved Safety Safety Safety Safety Safety Safety 
Output10| Output9| Output8| Output7| Output6| Outputs 
Status Status Status Status Status Status 
4 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 


5) Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Outputl0 | Output? 
Monitor | Monitor 


Instance | Byte Bit7 Bito Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2BChex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 


Input4 Input3 Input2 Inputl Inputl2 | Inputl1 | Inputl0 Input9 
Status Status Status Status 
2 Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl2 | Inputl1 | Inputl0 Input9 Input8 Input7 Input6 Tnput5 
Status Status Status Status Status Status Status Status 


sh Safety Safety Safety Safety Safety Safety Safety Safety 
Output8| Output7 | Output6| OutputS | Output4} Output3| Output2) Outputl 
Status Status Status Status Status Status Status Status 


4 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Output12} Outputi1) Outputl0) Output9 
Status Status Status Status 


5} Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | OutputS Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 


6 Reserved | Reserved | Reserved | Reserved Safety Safety Safety Safety 
Output!2 | Output! | OutputlO | Output9 
Monitor | Monitor | Monitor | Monitor 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2BDhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Input8 Input7 Input6 Input5 Input4 Input3 Input2 Inputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Input2 Input1 Inputi4 | Inputi3 | Inputi2 | Inputl1 | Inputl0 Input9 
Status Status 
2, Safety Safety Safety Safety Safety Safety Safety Safety 
Inputl0 | Input9 Input8 Input7 Input6 Tnput5 Tnput4 Input3 
Status Status Status Status Status Status Status Status 
3} Safety Safety Safety Safety Safety Safety Safety Safety 
Output4| Output3 | Output2|} Outputl| Inputl4 |} Inputi3 | Inputl2) Inputi1 
Status Status Status Status Status Status Status Status 
4 Safety Safety Safety Safety Safety Safety Safety Safety 
Outputl2) Outputl1) Outputl0} Output9} Output8| Output7| Output6| Outputs 
Status Status Status Status Status Status Status Status 
5 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Safety Safety 
Outputl4} Outputl3 
Status Status 
6 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
7 | Reserved | Reserved | Safety Safety | Safety Safety Safety | Safety 
Outputl4 | Output!3 | Output!2 | Output! 1 | OutputlO | Output 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
20h 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Standard Safety 
Output! Outputl 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl BitO 
2C2hex 0 Reserved | Reserved | Reserved | Reserved | Standard | Standard Safety Safety 
Output2 | Output! Output2} Outputl 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bit 
OBing 0 Standard | Standard | Standard | Standard Safety Safety Safety Safety 
Output4 | Output3 | Output2 | Output] Output4 | Output3) Output2} Output! 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
2C4 nex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | OutputS | Output4| Output3| Output2| Output 
1 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Output8 | Output7 | Output6 | OutputS Output4 | Output3 | Output2 | Output! 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2C5hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8| Output7 | Output6 | OutputS| Output4| Output3| Output2| Outputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Output16| Outputl5| Outputl4| Outputl3) Outputl2) Outputi1| Outputl0| Output9 
2 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Output8 | Output7 | Output6 | OutputS Output4 | Output3 | Output2 | Output! 
3 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl1 | OutputlO | Output9 
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Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2C6hex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | OutputS| Output4| Output3| Output2| Outputl 
1 Safety Safety Safety Safety Safety Safety Safety Safety 
Output16| Output15| Outputl4) Outputl3} Outputl2| Outputl1| Outputl0} Output? 
2; Safety Safety Safety Safety Safety Safety Safety Safety 
Output24| Output23| Output22| Output21) Output20) Outputl9| Outputls| Outputl7 
3) Safety Safety Safety Safety Safety Safety Safety Safety 
Output32) Output31/ Output30) Output29| Output28} Output27| Output26| Output25 
4 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Output8 | Output7 | Output6 | Outputs Output4 | Output3 | Output2 | Output! 
5) Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl! | OutputlO | Output9 
6 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Outputl8 | Outputl7 
a Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Output32 | Output31 | Output30 | Output29 | Output28 | Output27 | Output26 | Output25 
Instance | Byte Bit7 Bit6 BitS Bitd Bit3 Bit2 Bitl Bitd 
2CAnex 0 Standard | Standard Safety Safety Safety Safety Safety Safety 
Output2 | Output! Output6 | OutputS | Output4| Output3| Output2) Outputl 
1 Reserved | Reserved | Reserved | Reserved | Standard | Standard | Standard | Standard 
Output6 | OutputS | Output4 | Output3 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2CBhex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8| Output7 | Output6| OutputS| Output4| Output3| Output2| Outputl 
i Standard | Standard | Standard | Standard | Standard | Standard Safety Safety 
Output6 | OutputS | Output4 | Output3 | Output2 | Output! | Outputl0; Output9 
2 Reserved | Reserved | Reserved | Reserved | Standard | Standard | Standard | Standard 
Outputl0 | Output9 | Output8 | Output7 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2CChex 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8 | Output7 | Output6 | OutputS| Output4 | Output3 | Output2| Output 
1 Standard | Standard | Standard | Standard Safety Safety Safety Safety 
Output4 | Output3 | Output2 | Output! | Outputi2) Outputi1) Outputl0; Outputd 
2 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Outputl2 | Outputl1 | OutputlO | Output9 | Output8 | Output7 | Output6 | Outputs 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
2CDrx 0 Safety Safety Safety Safety Safety Safety Safety Safety 
Output8| Output7 | Output6 | OutputS | Output4| Output3 | Output2| Outputl 
1 Standard | Standard Safety Safety Safety Safety Safety Safety 
Output2 | Output! | Outputl4) Outputl3) Outputi2) Outputi1) Outputl0) Output9 
2 Standard | Standard | Standard | Standard | Standard | Standard | Standard | Standard 
Outputl0 | Output9 Output8 Output7 Output6 OutputS Output4 | Output3 
4 Reserved | Reserved | Reserved | Reserved | Standard | Standard | Standard | Standard 
Outputl4 | Outputl3 | Outputl!2 | Output! 
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Safety Discrete I/O Device, Type: 23 Hex 


6-6.8 Mapping I/O Assembly Data Attribute Components 
6-6.8.1 Standard Data Only Open Assemblies 

The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 

I/O device for the input assemblies with standard input data and no status. 

Table 6-6.14 Instance Numbers 181 -18DHEX 

Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Standard InputV Safety Discrete Input | 3Dpex N Standard Input 10 
Point Value 

6-6.8.2 Safety Data Only Open Assemblies 


The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 
I/O device for the input assemblies wit 


safety input data and no 


Table 6-6.15 Instance Numbers 201 -20Dyrx 


safety status. 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety InputN Safety Discrete Input | 3Dhex N Safety Input Logical | 7 
Point Value 


The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 


I/O device for the input assemblies wit 


safety input data and combined safety input status. 


Table 6-6.16 Instance Numbers 211 -21Dyrx 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety InputV Safety Discrete Input | 3Djex N Safety Input Logical | 7 
Point Value 
Safety Input Status | Safety Discrete Input | 3Ehex 1 Status >: 
Group 


The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 
W/O device for the input assemblies wit 


Table 6-6.17 Instance Numbers 221 -22Dyrx 


safety input data and ind 


ividual safety input status. 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety InputV Safety Discrete Input | 3Djex N Safety Input Logical | 7 
Point Value 
Safety Input Safety Discrete Input | 3Djex N Status 5 
Status Point 
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The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 


V/O device for the output assemblies with safety output data. 


Table 6-6.18 Instance Numbers 231 -23Dyrx 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety Output N Safety Discrete Output | 3Byex N Safety Output Value | 3 
Point 


The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 
individual safety output status. 


I/O device for the input assemblies wit 


Table 6-6.19 Instance Numbers 241 -24Dyrex 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety OutputV Safety Discrete Output | 3Bhex N Status 5 
Status Point 


The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 
safety input data, combined safety input status, and 


I/O device for the input assemblies wit 


combined safety output status. 


Table 6-6.20 Instance Numbers 252 -25Dyex 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 

Safety InputV Safety Discrete Input | 3Dhex N Safety Input Logical | 7 
Point Value 

Safety Input Status | Safety Discrete Input | 3E,.. 1 Status 5 
Group 

Safety Output Status | Safety Discrete Output | 3C,,.x 1 Status 5 
Group 


The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 


I/O device for the input assemblies wit 
individual safety output status. 


safety input data, individual safety input status, and 


Table 6-6.21 Instance Numbers 262 -26Dyrx 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety Input Safety Discrete Input | 3Dpex N Safety Input Logical |7 
Point Value 
Safety InputV. Safety Discrete Input | 3Djex N Status 5 
Status Point 
Safety Output Safety Discrete Output | 3Bnex N Status 5 
Status Point 
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Safety Discrete I/O Device, Type: 23 Hex 


The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 


W/O device for the input assemblies wit 
individual safety output status. 


safety input data, combined safety input status, and 


Table 6-6.22 Instance Numbers 270 -27Dyrx 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety InputN Safety Discrete Input | 3Dhex N Safety Input Logical | 7 
Point Value 
Safety Input Status | Safety Discrete Input | 3E hex 1 Status 5 
Group 
Safety Output Safety Discrete Output | 3Byex N Status 5 
Status Point 


Safety Data and Standard Data Open Assemblies 


The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 


W/O device for the input assemblies witl 


safety input data and standard input data. 


Table 6-6.23 Instance Numbers 281 -28Dyex 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety InputV. Safety Discrete Input | 3Djex N Safety Input Logical | 7 
Point Value 
Standard InputV Safety Discrete Input | 3Dhex N Standard Input 10 


(standard data) 


Point 


Value 


The following table indicates the I/O assembly Data attribute ma 


pping for the Safety Discrete 


I/O device for the input assemblies with safety input data and individual safety output monitor. 
Table 6-6.24 Instance Numbers 291 -29DyEx 
Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety InputV Safety Discrete Input | 3Dhex N Safety Input Logical | 7 
Point Value 

Safety Output Safety Discrete Output | 3Bhex N Output Port Value | 4 
Monitor Point 

(standard data) 
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The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 
W/O device for the input assemblies wit 
individual safety output monitor. 


safety input data, combined safety input status, and 


Table 6-6.25 Instance Numbers 2A1 -2ADyrx 
Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety InputN Safety Discrete Input | 3Dhex N Safety Input Logical | 7 
Point Value 
Safety Input Safety Discrete Input | 3Ejex 1 Status 5 
Status Group 
Safety Output Safety Discrete Output | 3Byex N Output Port Value | 4 
Monitor Point 
(standard data) 


The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 


I/O device for the input assemblies wit 


individual safety output status, and individual safety output monitor. 


Table 6-6.26 Instance Numbers 2B1 -2BDyrx 


safety input data, individual safety input status, 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety InputN Safety Discrete Input | 3Diex N Safety Input Logical | 7 
Point Value 

Safety Input. Safety Discrete Input | 3Dh¢x N Status 5 
Status Point 

Safety Output Safety Discrete Output | 3Byex N Status 5: 
Status Point 

Safety Output Safety Discrete Output | 3Bnex N Output Port Value [4 
Monitor Point 


(standard data) 


The following table indicates the I/O assembly Data attribute mapping for the Safety Discrete 
I/O device for the output assemblies with safety output data and standard output data. 


Table 6-6.27 Instance Numbers 2C1-2CDyrx 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety Output V Safety Discrete Output | 3Bhex N Safety Output Value | 3 
Point 
Safety Output NV Discrete Output Point | 09% .x N Value 3 
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6-7.1 


Safety Analog I/O Device, Type: 2Attex 


Safety Analog I/O Device 
Device Type: 2A hex 


A Safety Analog I/O Device type interfaces to one or more Safety I/O devices that do not have 
network capabilities. Examples include Safety analog temperature and pressure sensors and 
valve actuators. A Safety Analog I/O device provides CIP Safety network communications to a 


safety controller and exchanges safety input and output data with safety analog sensors and 


actuators. 


Object Model 


The Object Model in Figure 6-7.1represents a Safety Analog I/O Device. The Table below 


includes: 


the object classes present in this device 
whether or not the class is required 


eeee 


the number of instances present in each class 
Note: The Safety Analog Output Point, Safety Analog Output Group and Safety Dual 


Channel Output objects are included in higher level discussions of this profile for 


conceptual completeness. They are identified as future extensions to this profile. Details of 


these objects will be added as needed. 


Table 6-7.1 Objects Present in a Safety Analog I/O Device 


Object Class Option/Required of Instances 
Identity Required 1 
Message Router Required 1 
Link Specific Object(s) Required Ht 
Connection Required for DeviceNet Safety # 
Connection Manager Required for EtherNet/IP Safety 1 
Safety Validator Required # 
Safety Supervisor Required 1 
Assembly Required * 
Analog Input Point (AIP) Optional? bi 
Safety Analog Input Point (SAIP) Conditional’ * 
Analog Output Point (AOP) Optional’ * 
Safety Analog Output Point (SAOP) Conditional” + 


Safety Dual Channel Analog Output (SDCAO) 


Conditional? 


Safety Dual Channel Analog Input (SDCAI) Conditional? * 
Analog Input Group (AIG) Optional 1 
Safety Analog Input Group (SAIG) Optional 1 
Analog Output Group (AOG) Optional 1 
Safety Analog Output Group (SAOG) Optional 1 
* = # of instances depends on the level of I/O supported by the product. 

# = Depends on the level of safety IO connections supported by the product. 

Ht = Depends on the number of network interfaces supported on the product. 

1 = Required for Safety Input Functions 

2 = Required for Safety Output Functions 
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Object Class Option/Required # of Instances 


3 = Optional for Standard Input Functions 
4 = Optional for Standard Output Functions 
5 = Required for Safety Input/Output Dual Channel Functions 


Figure 6-7.1 Object Model for Safety Analog I/O Device 


Safety Analog 
Input Point Class. 


Analog Input 
Point Class 


\alog Input Class 


Connection Class 
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6-7.2.1 


Safety Analog I/O Device, Type: 2Attex 


How Objects Affect Behavior 


The objects for this device affect the device’s behavior as shown in the table below. 


Table 6-7.2 Object Affect on Behavior 


Object 


Effect on Behavior 


Identity 


No effect 


Message Router 


No effect 


Link Specific Object 


Configures communication link attributes 


Connection (Manager) Object 


Contains the logical ports into and out of the device 


Assembly 


Defines structure of the data available to standard and safety 
I/O connections and used to configure the device. 


Safety Supervisor 


Implements the Safety Network Configuration Tool Interface 


Safety Validator 


Performs the high integrity functions required for CIP Safety 
connections 


Analog Input Point (AIP) 


Defines behavior of the standard Analog Input Points for this 
device 


Safety Analog Input Point 
(SAIP) 


Defines behavior of the safety Analog Input Points for this 
device 


Analog Output Point (AOP) 


Defines behavior of the standard Analog Output Points for this 
device 


Safety Analog Output Point 
(SAOP) 


Defines behavior of the safety Analog Output Points for this 
device 


Safety Dual Channel Analog 
Input 


Defines behavior of the Safety Dual Channel Analog Inputs 
for this device 


Safety Dual Channel Analog 
Output 


Defines behavior of the Safety Dual Channel Analog Outputs 
for this device 


Analog Input Group 


Stores the grouped attributes of the Analog Input Points 


Safety Analog Input Group 


Stores the grouped attributes of the Safety Analog Input Points 


Analog Output Group 


Stores the grouped attributes of the Analog Output Points 


Safety Analog Output Group 


Stores the grouped attributes of the Safety Analog Output 
Points 


Safety Supervisor Requirements 


The safety supervisor definition contains a number of “profile dependent” functions. This 
section defines what the required behavior shall be for the Safety Analog I/O device profile. 


Table 6-7.3 Safety Supervisor Implementation Level 


Implementation Level Profile Requirement 
Baseline functionality Required 
SNCT functionality Optional 


=6-47- 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 6: Device Profiles 


6-7.3 


Safety Analog I/O Device, Type: 2Attex 


Table 6-7.4 Safety Supervisor Profile-dependent State Event Behavior 


Event 


“IDLE” State 
Behavior 


“Executing” State Behavior 


Comments 


Safety Connection 


Remain in IDLE 


If any standard or safety /O 


Tn this profile, device is 


Failed/Closed connection still open, remain in IDLE unless at least 
in EXECUTING, one standard or Safety 
Else, 1/O connection is 
Transition to IDLE established 

Standard or Safety 1/0. Transition to Remain in EXECUTING state 


Connection established 


EXECUTING 


Type 1 Safety Open 


Configure device, 


transition to 
EXECUTING 


Drop standard and safety 1/O 
connections, configure device, 
return to EXECUTING 


Safety I/O Connection 
Deleted 


Not supported 


Not supported 


Connection deletion not 
supported 


Safety Supervisor Mode 
Change 


Error response: 
"Service Not 
Supported” 


Error response: 
Service Not Supported” 


No mode change defined 
for this profile 


Defining Object Interfaces 


The objects in this device have the interfaces listed in the following table. 


Table 6-7.5 Object Interfaces 


Object 


Interface 


Tdentity 


Message Router 


Message Router 


Explicit Messaging Connection Instance 


DeviceNet 


Message Router 


Connection 


Message Router 


Connection Manager 


Message Router 


Assembly 


I/O Connection (for standard connections) or Safety Validator (for 
Safety I/O connections) or Message Router 


Safety Supervisor 


Message Router 


Safety Validator 


Message Router or Safety I/O Connection 


Analog Input Point (AIP) 


Message Router or Assembly Object 


Safety Analog Input Point 
(SAIP) 


Message Router or Assembly Object 


Safety Dual Channel Analog 


Message Router or Assembly Object 


Input (SDCAT) 

Safety Dual Channel Analog Message Router or Assembly Object 
Output (SDCAOT) 

Analog Output Point (AOP) Message Router or Assembly Object 


Safety Analog Output Point 
(SAOP) 


Message Router or Assembly Object 


Safety Dual Channel Output 


Message Router or Assembly Object 


Analog Input Group 


Message Router 


Safety Analog Input Group 


Message Router 


Analog Output Group 


Message Router 


Safety Analog Output Group 


Message Router 


— 6-48 — 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 6: Device Profiles 


6-7.4 


6-7.5 


6-7.6 


Safety Analog I/O Device, Type: 2Attex 


Relationship between AIP and SAIP 


A module using the Safety Analog I/O profile may support either the SAIP, AIP, or both. An 
instance of the SAIP can be used to access inputs via safety evaluated data, or to access inputs 
as standard inputs without safety evaluation. An Instance of the AIP can be used as standard 
Analog input data which is equivalent to the SAIP input data without safety evaluation (Input 
Channel Mode set to Standard). 


Relationship between AOP and SAOP 


A module using the Safety Analog I/O profile may support either the SAOP, AOP, or both. An 
instance of the SAOP can be used to drive outputs in a high integrity manner, or to drive 
outputs as standard outputs with the high integrity validation disabled. An Instance of the AOP 
can be used as standard Analog output data which is equivalent to the SAOP output data 
without safety evaluation. 


1/O Assembly Instances 


The I/O Assemblies for the Safety Analog I/O Device may be classified into the following 
types. 


Table 6-7.6 I/O Assembly Object Instances for the Safety Analog I/O Device 


Input or Output Data Type 
Input Standard Data Only 
Input Safety Data Only 
Input Safety and Standard Data 
Output Standard Data Only 
Output Safety Data Only 
Output Safety and Standard Data 


The assembly instance definitions will differentiate safety data from standard data. Assembly 
instances that contain Safety Data shall be implemented in a high integrity manner. 


When an input assembly can be accessed by both a Safety I/O connection and/or a Standard I/O 
connection, the same instance number will be used by either I/O connection type. 


When an output assembly can be accessed by a Safety I/O connection or a Standard I/O 
connection, the same instance number will be used by either of the I/O connection types. Only 
one I/O connection can be made to an output assembly, or object, at any given time. 


This profile will define Safety and Standard Data assemblies that are mapped to the SAIP that 
provide functionality comparable to AIP, but don’t require the support of or the additional 
configuration of the AIP. These assemblies will be defined in the 180 — 2FF,,.x instance range. 


As denoted in the table below instance number ranges 01-63). and 100-17F hex of this profile 
will be reserved for definition by a General Purpose Analog I/O Profile. Those assembly 
definitions and mapping will not be repeated in this profile. 
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Table 6-7.7 Instance Number Ranges 


Instance Assembly Instance ID Profile that defines | Typical Uses 
Range from Assembly the Assembly 
ny Nt Data T, 
we Object Table 6.A Qty cates Instance 

01-63hex Open (static assemblies 99 Standard Data General Purpose AIP or AOP 
defined in device profile) Only Analog /O based I/O data 

64-CThex Vendor Specific static 100 Vendor Specific | Vendor Specific AIP or AOP 
assemblies and dynamic based I/O data 
assemblies 


C8-FFhex Reserved by CIP for future 56 
use 


100-17 Fhex Open (static assemblies 128 Standard Data General Purpose AIP or AOP 
defined in device profile) Only Analog I/O based I/O data 
180-1 FF hex Open (static assemblies 128 16 bit Safety Safety Analog I/O. SAIP or SAOP 
defined in device profile) and Standard (this profile) based safety 
Data and standard 
VO data 
200-2FFhex Open (static assemblies 192 32 bit Safety Safety Analog I/O SAIP or SAOP 
defined in device profile) and Standard (this profile) based safety 
Data and standard 
1/O data 
300-4FFhex Vendor Specific static 512 Vendor Specific | Vendor Specific 
assemblies and dynamic 
assemblies 


500-FFFFy¢x Reserved by CIP for future | 64,256 | - - 
use 


As denoted in the table above instance number range 180-2FF,-x will be defined in this profile. 


Safety and Standard Data Open Assemblies 


The following safety and standard data assemblies will be defined to allow access to the Safety 
V/O points as standard I/O points without having to support the AIP object. The Standard 
Input(7) data in these assemblies maps to the Safety Analog Input Value attribute of the SATP. 
It is left to the application to configure and monitor the Safety versus Standard behavior of the 
SAIP. The Analog Input (n) data maps to the Value attribute of the AIP. 


This Individual Status used the in the following tables refers to the value of the SAIP attribute 
Input Point Status, which is the status of the individual analog channel. 


The Safety Analog Input Point Object specifies that 8 bit, 16 bit, 32 bit and 64 bit data types 
may be implemented in that object. The initial revision of this profile defines assemblies for the 
16 bit and 32 bit data types. Assemblies for other data types may be added to this profile in the 
future, or implemented as vendor specific assemblies. 
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I/O Device, Type: 2Attex 


Table 6-7.8 Safety Data Open INT type Input Assembly Instances 


Safety I/O Individual 
Status 
Instance INT Number of Input Point 
Number Type Safety Inputs Status (n) 
180hex In 1 
18] nex In 2 
TB 2hex In 4 
183hex In 6 
184 hex In 8 
185 hex In 10 
186hex In 12 
187 hex In 14 
188hex In 16 
189 hex In 18 
18Anex In 20 
18Bhex In 24 
18Chex In 28 
18Dhex In 32 
190 hex In 1 1 
19 hex In 2 2 
192nex In 4 4 
193 hex In 6 6 
194 hex In 8 8 
195 hex In 10 10 
196hex In 12 12 
197hex In 14 14 
198 hex In 16 16 
199 bx In 18 18 
19 Avex In 20 20 
19Bhex In 24 24 
19Chex In 28 28 
19D hex In 32 32 
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Table 6-7.9 Safety Data Open INT type Output Assembly Instances 


Safety I/O Individual 
Status 
Instance INT Number of Tnput Point 
Number Type Safety Outputs Status (n) 
IBOpex Out 
IBI hex Out 2 
IB2hex Out 4 
1H ie Out 6 
IBA nex Out 8 
TES ye Out 10 
1B6,ex Out 12 
IBThex Out 14 
IBB8hex Out 16 
IB pcx Out 18 
IBAnex Out 20 
IBByex Out 24 
IBChex Out 28 
IBDhpex Out 32 
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Table 6-7.10 Safety Data Open UINT type Input Assembly Instances 


Safety I/O Individual 
Status 
Instance UINT Number of Input Point 
Number Type Safety Inputs Status (n) 
1COpex In 1 
TCT pax In 2 
ilar In 4 
1 Fics In 6 
1C4hex In 8 
TOS In 10 
1C6 ex In 12 
1CTig In 14 
1CB8hex In 16 
19:68 In 18 
1CAnex In 20 
ICByex In 24 
1CCyex In 28 
1CDhex In 32 
1D0 hex In 1 1 
IDI hex In 2 2 
1D2hex In 4 4 
IDB hex In 6 6 
1D 4 nex In 8 8 
1DS nex In 10 10 
1D6nex In 12 12 
ID7hex In 14 14 
IDBhex In 16 16 
ID 9pex In 18 18 
IDApex In 20 20 
IDBhex In 24 24 
IDChex In 28 28 
IDDhex In 32 32 
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Table 6-7.11 Safety Data Open UINT type Output Assembly Instances 


Safety I/O Individual 
Status 
Instance UINT Number of Tnput Point 
Number Type Safety Outputs Status (n) 
1FOpex Out 
IF liex, Out 2 
1F 2px Out 4 
IF 3hex Out 6 
1F4 ex Out 8 
IF Sex Out 10 
1F6 pox Out 12 
IFT hex Out 14 
IF 8hex Out 16 
IF 9px Out 18 
IFAnex Out 20 
LFBhex Out 24 
TFC hex Out 28 
IFDhex Out 32 
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Table 6-7.12 Safety Data Open DINT type Assembly Instances 


Safety I/O Individual 
Status 
Instance DINT Number of Tnput Point 
Number Type Safety Inputs. Status (n) 
200hex In 1 
20Ihex In 2 
202 hex In 4 
203 hex In 6 
204 nex In 8 
205 hex In 10 
206 rex In 12 
207hex In 14 
208hex In 16 
209 nex In 18 
20Anex In 20 
20Brex In 24 
20C hex In 28 
20Dhex In 32 
210 hex In 1 1 
DW ee In 2 2 
212nex In 4 4 
DF In 6 6 
24x In 8 8 
21S nex In 10 10 
216hex In 12 12 
217hex In 14 14 
218hex In 16 16 
21 bx In 18 18 
21Ahex In 20 20 
2B, In 24 24 
21C ex In 28 28 
21D hex In 32 32 
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Table 6-7.13 Safety Data Open DINT type Output Assembly Instances 


Safety I/O Individual 
Status 
Instance DINT Number of Tnput Point 
Number Type Safety Outputs Status (n) 
230hex Out 
231 nex Out 2 
dic Out 4 
Pei Out 6 
Pxy ae Out 8 
Ba5 Out 10 
236 hex Out 12 
237hex Out 14 
238hex Out 16 
239 nex Out 18 
23 Anex Out 20 
23Bhex Out 24 
23Chex Out 28 
23Dhex Out 32 
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Table 6-7.14 Safety Data Open UDINT type Assembly Instances 


Safety I/O Individual 
Status 
Instance UDINT Number of Input Point 
Number Type Safety Inputs Status (n) 
240nex In 1 
24 Mhex In 2 
99... In 4 
Sis. In 6 
244 pen In 8 
BAS: In 10 
246 rex In 12 
247 nex In 14 
248hex In 16 
249 nex In 18 
24Ahex In 20 
24Brex In 24 
24C rex In 28 
24D hex In 32 
250 yex In 1 1 
DSi In 2 2 
252i In 4 4 
253 rex In 6 6 
54iex In 8 8 
255nex In 10 10 
256 nex In 12 12 
257hex In 14 14 
258hex In 16 16 
259 bx In 18 18 
25Ahex In 20 20 
25B ix In 24 24 
250... In 28 28 
25Dhex In 32 32 
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Table 6-7.15 Safety Data Open UDINT type Output Assembly Instances 


Safety I/O Individual 
Status 

Instance UDINT Number of Tnput Point 
Number Type Safety Outputs Status (n) 

270nex Out 

27 ex Out 2 

D7 Dies Out 4 

S7is. Out 6 

T7A,. Out 8 

B7Sie Out 10 

276 hex Out 12 

27 Trex Out 14 

278hex Out 16 

279 na, Out 18 

27Anex Out 20 

27Bhex Out 24 

27 Chcx Out 28 

27Dhex Out 32 
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Table 6-7.16 Safety Data Open REAL type Input Assembly Instances 


Safety I/O Individual 
Status 
Instance REAL Number of Input Point 
Number Type Safety Inputs Status (n) 
280hex In 1 
28 Inex In 2 
ae In 4 
O83 ,5. In 6 
2B4 nex In 8 
prea In 10 
2BOpex In 12 
287hex In 14 
288hex In 16 
289 nex In 18 
28Anex In 20 
28Bhex In 24 
28Chex In 28 
28Dhex In 32 
290 hex In 1 1 
Wier In 2 2 
292nex In 4 4 
WB pe In 6 6 
294 nex In 8 8 
295 irex In 10 10 
296 nex In 12 12 
297 hex In 14 14 
298hex In 16 16 
299: In 18 18 
29Arrex In 20 20 
29Bhex In 24 24 
29Chex In 28 28 
29D hex In 32 32 
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Table 6-7.17 Safety Data Open REAL type Output Assembly Instances 


Safety /O Individual 
Status 

Instance REAL Number of Input Point 

Number Type Safety Outputs Status (n) 
2BOnex Out 1 
2B hex Out 2 
2B2hex Out 4 
2B3 hex Out 6 
2B4 nex Out 8 
2B5hex Out 10 
2B6nex Out 12 
2B7 hex Out 14 
2BB8 hex Out 16 
2BYnex Out 18 
2BAtex Out 20 
IBBhex Out 24 
2BChex Out 28 
2BDpex Out 32 


The following tables define Status Data Only Assemblies. 


Table 6-7.18 Safety and Standard Status Data Assembly Instances 


Individual Fault Alarm 
Status Reason Warning 
Instance | Status Number of Fault Alarm 
Number Input Point | Reason (n) | Warning 
Status (n) 

2COhex In 1 

2CThes In es 

2C2hex In 4 

2C3 hex In 6 

2C4 nex In 8 

2C5 tex In 10 

206: In 12 

2CThex In 14 

2CBnex In 16 

2C9pex In 18 

ICA ins In 20 

ICH In 24 

2CGiex In 28 

2CD hex In 32 
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Fault Alarm 
Reason Warning 
Instance | Status Fault Alarm 
Number Reason (n) | Warning 
(n) 
D0 hex In 1 
Piel a In 2 
2D In 4 
2D3 hex In 6 
2D4 nex In 8 
2D5 nex In 10 
2D6 nex In 12 
2D7Thex In 14 
2DBhex In 16 
2D9hex In 18 
2DAtex In 20 
SDB In 24 
SG In 28 
2DD hex In 32 
Fault Alarm 
Reason Warning 
Instance | Status Fault Alarm 
Number Reason (n) | Warning 
(n) 
2EQhex In 1 1 
QE I hex In 2 2 
ZEA. In 4 4 
2E3p ex In 6 6 
2E4 nex In 8 8 
2ES nex In 10 10 
2E6nex In 12 12 
2EThex In 14 14 
2EB8hex In 16 16 
QEMnex In 18 18 
2EAtex In 20 20 
QEBhex In 24 24 
2EChex In 28 28 
QED px In 32 32 
- 6-61 - 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 6: Device Profiles 


6-7.7 


6-7.7.1 


Safety Analog I/O Device, Type: 2Attex 


Individual Individual 
Status Monitor 
Instance | Status Number of Number of 
Number Safety Output 
Outputs Monitors 
2FO hex In 1 1 
IF lex In 2 2 
aP., In 4 4 
2F 3 hex In 6 6 
2FAnex In 8 8 
2FShex In 10 10 
2FOnex In 12 12 
2F Tex In 14 14 
2F8hex In 16 16 
2PO jax In 18 18 
2FAnex In 20 20 
2FBhex In 24 24 
2EC ix In 28 28 
2FDhex In 32 32 


I/O Assembly Data Attribute Format 


The following sections define the IO data assemblies supported by the Safety Analog IO device 
type profile. Since these assemblies transfer analog data, the assembly sizes are large for even a 
few IO points. In order to make the following sections more readable, an abbreviated 
presentation style was used. For assemblies with six or less IO points, each data element is 
explicitly specified. For all other assemblies, an ellipsis (...) is used in the tables to indicate 
that the pattern established for the first two IO points is continued for the next number of IO 
points as needed to fill out the assembly. Additionally, rows in the tables show the Input (n) IO 
size in INT, UNIT, DINT, UDINT or REAL types for each IO point. Therefore, each entry for 
a single IO point in the assembly definition tables represents either two or four bytes of data. 
The actual byte count for the assemblies is listed in the “Byte” column of the tables. 


Safety and Standard Data Open Assemblies 


The assemblies described in this section are defined to access the Safety I/O points as safe or 
standard I/O points. The Input (7) data in these assemblies maps to the Safety Analog Input 
Value attribute of the SATP. Refer to section 6-7.8, Mapping IO Assembly Data Components. 
These assemblies may be accessed by either safety or standard IO connections. 


Table 6-7.19 indicates that the INT and UINT data type Assemblies that have the same data 
content and the same number of IO points have the same format. The only difference is the 
Assembly Id. For example, the data format definitions for Assembly Id 180)-x and Assembly 
Id 1COpex are the same. Assembly Id 181 format and Assembly Id 1C1 format is the same, 
Assembly Id 191 format and Assembly Id 1D1 format is the same, and so forth for the rest of 
the Assembly Ids specified. 
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Table 6-7.19 Safety and Standard Data 16 Bit Data Types and Assembly Instances 


Number of IO Points 
Data 1 2 4 6 8 10 ab 14 16 18 20 24 28 32 
Type 
Input Data only assemblies 
INT 180 | 181 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 18A | 18B | 18C | 18D 
UINT 1CO | 1C1 | 1C2 | 1C3. | 104 | ICS | 1C6. | 1C7 | 1C8 | 1C9 | 1CA | 1CB | 1CC | 1cD 
Input Data and Status assemblies 
INT 190 | 191 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 19A | 19B | 19C | 19D 
UINT 1D0 | IDI | 1D2 | 1D3 | 1D4 | 1D5 | 1D6 | 1D7 | 1D8 | 1D9 | 1DA | IDB | IDC | IDD 
Output Data only assemblies 
INT 1BO | I1B1 | 1B2 | 1B3 | 1B4 | 1BS | 1B6 | 1B7 | IB8 | 1B9 | IBA | 1BB | IBC | IBD 
UINT 1FO | IFI 1F2 | 1F3 | 1F4 | 1F5 | 1F6 | 1F7 | IF8 | 1F9 | 1FA | 1FB | IFC | IFD 
Table 6-7.20 Safety and Standard Data 16 Bit Open Assembly Instances 
Instance | Byte High Byte Low Byte 
180hex | 0,1 Input | Input 1 
1COnex 
Instance | Byte High Byte Low Byte 
ites | Input | Input 1 
1Clhex ole} Input 2 Tnput 2 
Instance | Byte High Byte Low Byte 
| Input 1 Input 1 
IG oes} Input 2 Input 2 
45 Input 3 Input 3 
6,7 Input 4 Input 4 
Instance | Byte High Byte Low Byte 
183 hex 0,1 Input 1 Input 1 
1C3pex BS Input 2 Input 2 
4,5 Input 3 Input 3 
6,7 Input 4 Input 4 
8,9 Input 5 Input 5 
10,11 Input 6 Input 6 
Instance | Byte High Byte Low Byte 
184 | O,1 Input 1 Input 1 
1C4yex | 2,3 Input 2 Input 2 
12,13 Input 7 Input 7 
14,15 Input 8 Input 8 
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Instance | Byte High Byte Low Byte 
kes Ou Input 1 Input 1 
1S 2g) Input 2 Input 2 

16,17 Input 9 Input 9 
18,19 Input 10 Input 10 

Instance | Byte High Byte Low Byte 
186}ex 0,1 Input 1 Input 1 
1C6yex | 2,3 Input 2 Input 2 

20,21 Input 11 Input 11 
22,23 Input 12 Input 12 

Instance | Byte High Byte Low Byte 
187hex 0,1 Input 1 Input | 
Here. [fees Input 2 Input 2 

24,25 Input 13 Input 13 
26,27 Input 14 Input 14 

Instance | Byte High Byte Low Byte 
188hex | 0,1 Input 1 Input 1 
1C8hex 2,3 Input 2 Input 2 

28,29 Input 15 Input 15 
30,31 Input 16 Input 16 

Instance | Byte High Byte Low Byte 
189 hex 0,1 Input 1 Input 1 
1C9pex 2,3 Input 2 Input 2 

32)33 Input 17 Input 17 
34,35 Input 18 Input 18 

Instance | Byte High Byte Low Byte 
18Apex | 0,1 Input | Input | 
ICAjex || 2,3 Input 2 Input 2 

36,37 Input 19 Input 19 
38,39 Input 20 Input 20 
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Instance | Byte High Byte Low Byte 
18By, | 0,1 Input 1 Input 1 
1CBhex 2,3 Input 2 Input 2 
44,45 Input 23 Input 23 
46,47 Input 24 Input 24 
Instance | Byte High Byte Low Byte 
18C hex 0,1 Input 1 Input 1 
1CChee 2,3 Input 2 Input 2 
52,53 Input 27 Input 27 
34,55 Input 28 Input 28 
Instance | Byte High Byte Low Byte 
18Dpex | 0,1 Input 1 Input | 
ike (fs Input 2 Input 2 
60,61 Input 31 Input 31 
62,63 Input 32 Input 32 
Table 6-7.21 Safety and Standard Data 16 bit Open Assembly Instances with Status 
Instance | Byte High Byte Low Byte 
190hex. 0,1 Input 1 Input 1 
1D0bex Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Input! 
Status 
Instance | Byte High Byte Low Byte 
191 nex. 0,1 Input 1 Input 1 
1D I hex 233) Input 2 Input 2 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bito 
4 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Input2 Input! 
Status Status 
Instance | Byte High Byte Low Byte 
192, 0,1 Input | Input | 
1D%x |) 23 Input 2 Input 2 
45 Input 3 Input 3 
6,7 Input 4 Input 4 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bito 
8 | Reserved | Reserved | Reserved | Reserved | Input4 Input3 Input2 Input! 
Status Status Status Status 
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Instance | Byte High Byte Low Byte 
19B3hex. 0,1 Input 1 Input 1 
1D 3 hex. 23 Input 2 Input 2 
45 Input 3 Input 3 
6,7 Input 4 Input 4 
8.9 Input 5 Input 5 
10,11 Input 6 Input 6 
Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bit 
12 Reserved | Reserved Input6 Input Input4 Input3 Input2 Input! 
Status Status Status Status Status Status 
Instance | Byte High Byte Low Byte 
194 nex 0,1 Input 1 Input | 
1D4 hex 2,3 Input 2 Input 2 
13,14 Input 7 Input 7 
14,15 Input 8 Input 8 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bito 
16 Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
Instance | Byte High Byte Low Byte 
195 hex 0,1 Input 1 Input | 
ieee |e Input 2 Input 2 
16,17 Input 9 Input 9 
18,19 Input 10 Input 10 
Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
20 Input8 Input7 Input6 Tnput5S Input4 Input3 Input2 Input 
Status Status Status Status Status Status Status Status 
21 | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Inputl0 Tnput9 
Status Status 
Instance | Byte High Byte Low Byte 
196 nex 0,1 Input | Input I 
ID6he || 23 Input 2 Input 2 
20,21 Input 11 Input 11 
22,23 Input 12 Input 12 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
24 Input8 Input7 Input6 InputS Input4 Input3 Input2 Inputl 
Status Status Status Status Status Status Status Status 
25 | Reserved | Reserved | Reserved | Reserved | Inputl2 | Inputl1 Input10 Input? 
Status Status Status Status 
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Instance | Byte High Byte Low Byte 
eye Ou Input 1 Input 1 
IDThex 23 Input 2 Input 2 
24,25 Input 13 Input 13 
26,27 Input 14 Input 14 
Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
28 Input8 Input7 Input6 Input Tnput4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
29 Reserved | Reserved | Inputl4 Input13 Inputl2 Input! 1 InputlO Input9 
Status Status Status Status Status Status 
Instance | Byte High Byte Low Byte 
ose || MON Input 1 Input 1 
1D8hex 2,3 Input 2 Input 2 
28,29 Input 15 Input 15 
30,31 Input 16 Input 16 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bito 
32 Input8 Input7 Tnput6 Tnput5 Tnput4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
33 | Inputl6 | Inputis | Inputi4 | Inputt3 | Inputi2 | Inputit | Inputio | Inpurd 
Status Status Status Status Status Status Status Status 
Instance | Byte High Byte Low Byte 
199 pox 0,1 Input 1 Input | 
1D%ex | 2,3 Input 2 Input 2 
epee Input 17 Input 17 
34,35 Input 18 Input 18 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
36 Input8 Input7 Input6 Tnput5 Tnput4 Input3 Tnput2 Input! 
Status Status Status Status Status Status Status Status 
37 | Inputl6 | Inputts | Inputt4 | Inputt3 | Inputl2 | Inputit | Inputio | Inpurd 
Status Status Status Status Status Status Status Status 
38 | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Inputl8 | Inputl7 
Status Status 
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Instance | Byte High Byte Low Byte 
19Apex | 0,1 Input 1 Input 1 
IDAhex 2,3 Input 2 Input 2 
36,37 Input 19 Input 19 
38,39 Input 20 Input 20 
Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bit1 Bito 
40 Input8 Input7 Input6 Input Tnput4 Input3 Tnput2 Input! 
Status Status Status Status Status Status Status Status 
4l Inputl6 Inputl5 Inputl4 Inputl3 Inputl2 Input! 1 InputlO Input9 
Status Status Status Status Status Status Status Status 
42 Reserved | Reserved | Reserved | Reserved | Input20 Tnputl9 Input18 Inputl7 
Status Status Status Status 
Instance | Byte High Byte Low Byte 
19Bhex 0,1 Input 1 Input | 
HD Bees |e Input 2 Input 2 
44,45 Input 23 Input 23 
46,47 Input 24 Input 24 
Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bit1 Bitd 
48 | Input8 Input7 Tnput6 InputS | Input4 | Input3 | Input2 | Input! 
Status Status Status Status Status Status Status Status 
49 Input!6 InputlS Inputl4 TInput!3 Input!2 Input! 1 TInputlO Input? 
Status Status Status Status Status Status Status Status 
50 Input24 Input23 Input22 Input21 Input20 Inputl9 Input 18 Inputl7 
Status Status Status Status Status Status Status Status 
Instance | Byte High Byte Low Byte 
19C hex 0,1 Input 1 Input | 
ie. |e Input 2 Input 2 
52,53 Input 27 Input 27 
54,55 Input 28 Input 28 
Bit7 Bit6 Bits Bit4 Bit3 Bit2 Bitl Bito 
56 Input8 Input7 Input6 InputS Input4 Input3 Tnput2 Input! 
Status Status Status Status Status Status Status Status 
et Inputl6 | Inputl5 Inputl4 | Inputl3 | Inputl2 | Input! Inputl0 Input? 
Status Status Status Status Status Status Status Status 
58 Input24 Input23 Input22 Input21 Input20 Tnputl9 Input!8 Inputl7 
Status Status Status Status Status Status Status Status 
59 Reserved | Reserved | Reserved | Reserved | Input28 Input27 Input26 Tnput25 
Status Status Status Status 
— 6-68 — 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Analog I/O Device, Type: 2Attex 


Instance | Byte High Byte Low Byte 
19Dpex | 0,1 Input 1 Input 1 
IDD hex 2,3 Input 2 Input 2 
60,61 Input 31 Input 31 
62,63 Input 32 Input 32 

Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 

64 Input8 Input7 Input6 InputS Tnput4 Input3 Input2 Tnputl 

Status Status Status Status Status Status Status Status 

65 Inputl6 Input!S Inputl4 Input13 Inputl2 Input! 1 InputlO Input9 

Status Status Status Status Status Status. Status Status 

66 Input24 Input23 Input22 Input21 Input20 Tnputl9 Input18 Inputl7 

Status Status Status Status Status Status Status Status 

67 Input32 Tnput31 Input30 Input29 Input28 Input27 Input26 Input25 

Status Status Status Status Status Status Status Status 


Table 6-7.22 Safety and Standard Data 16 bit Open Ow 


itput Assembly Instances 


Instance | Byte High Byte Low Byte 
TBOS || Oj Output 1 Output 1 
1FOhex 

Instance | Byte High Byte Low Byte 
TBI hex 0,1 Output 1 Output | 
IE Tex 2,3 Output 2 Output 2 

Instance | Byte High Byte Low Byte 
TB2hex 0,1 Output 1 Output 1 
1F2h x 2,3 Output 2 Output 2 

4,5 Output 3 Output 3 
6,7 Output 4 Output 4 

Instance | Byte High Byte Low Byte 
BS pee || Ror Output 1 Output 1 
The 278) Output 2 Output 2 

4,5 Output 3 Output 3 
6,7 Output 4 Output 4 
8,9 Output 5 Output 5 
10,11 Output 6 Output 6 

Instance | Byte High Byte Low Byte 
1B4 nex 0,1 Output | Output 1 
1F4 hex 23 Output 2 Output 2 

12,13 Output 7 Output 7 
14,15 Output 8 Output 8 
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Instance | Byte High Byte Low Byte 
iispee | ROul Output 1 Output 1 
TF5hex 25 Output 2 Output 2 

16,17 Output 9 Output 9 
18,19 Output 10 Output 10 

Instance | Byte High Byte Low Byte 
IB6pex 0,1 Output 1 Output 1 
1F6 nex 2,3 Output 2 Output 2 

20,21 Output 11 Output 11 
22,23 Output 12 Output 12 

Instance | Byte High Byte Low Byte 
IBThex 0,1 Output 1 Output 1 
1FThex | 2,3 Output 2 Output 2 

24,25 Output 13 Output 13 
26,27 Output 14 Output 14 

Instance | Byte High Byte Low Byte 
1B8yex | 0,1 Output 1 Output 1 
1F8hex. 23 Output 2 Output 2 

28,29 Output 15 Output 15 
30,31 Output 16 Output 16 

Instance | Byte High Byte Low Byte 
TB9 jx 0,1 Output | Output | 
TF pcx. 2,3 Output 2 Output 2 

32,33 Output 17 Output 17 
34,35 Output 18 Output 18 

Instance | Byte High Byte Low Byte 
IBAjex 0,1 Output 1 Output 1 
IFAtes, rie) Output 2 Output 2 

36,37 Output 19 Output 19 
38,39 Output 20 Output 20 
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Instance | Byte High Byte Low Byte 
IBByex | 0,1 Output 1 Output 1 
TFB hex 2,3 Output 2 Output 2 
44,45 Output 23 Output 23 
46,47 Output 24 Output 24 
Instance | Byte High Byte Low Byte 
1BChex 0,1 Output 1 Output 1 
TFC hex 2,3 Output 2 Output 2 
52,53 Output 27 Output 27 
54,55 Output 28 Output 28 
Instance | Byte High Byte Low Byte 
IBDhex 0,1 Output 1 Output 1 
1FDyex | 2,3 Output 2 Output 2 
60,61 Output 31 Output 31 
62,63 Output 32 Output 32 
The following table indicates that the 32-bit data type Assemblies defined in this profile with 
the same data content and the same numbers of IO points have the same format. The only 
difference is the Assembly Id. For example, the data definitions for Assembly Id 200). and 
Assembly Id 240 pex and 280 nex are the same. Assembly Id 201).x and Assembly Id 241)., and 


281 hex are the same, Assembly Id 211 hex and Assembly Id 251 ex and 291 nex are the same, and 


so forth for the rest of the Assembly Ids specified. 


Table 6-7.23 Safety and Standard Data 32 bit Data Types and Assembly Instances 


Number of IO Points 
Data 1 2 4 6 8 10 12 14 | 16 18 20 24 28 32 
Type 
Input Data only assemblies 
DINT 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 20A | 20B | 20C | 20D 
UDINT | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 24A | 24B | 24C | 24D 
REAL 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 28A | 28B | 28C | 28D 
|_ Input Data and Status assemblies _ 
DINT 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 21A | 21B | 21C | 21D 
UDINT | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 25A | 25B | 25C | 25D 
REAL 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 29A | 29B | 29C | 29D 
utput Data only assemblies 

DINT 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 23A | 23B | 23C | 23D 
UDINT | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 27A | 27B | 27C | 27D 
REAL 2B0 | 2BI | 2B2 | 2B3 | 2B4 | 2B5 | 2B6 | 2B7 | 2B8 | 2B9 | 2BA | 2BB | 2BC | 2BD 
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Table 6-7.24 Safety and Standard Data 32 bit Open Assembly Instances 


Instance | Byte High Byte Byte Byte Low Byte 
200 hex. 0-3 Input 1 Input 1 Input 1 Input 1 
240 ex 
280 hex 

Instance | Byte High Byte Byte Byte Low Byte 
201 hex 0-3 Input 1 Input 1 Input 1 Input 1 
241 hex 4-7 Input 2 Input 2 Input 2 Input 2 
281 hex 

Instance |_ Byte High Byte Byte Byte Low Byte 
202hex 0-3 Input 1 Input 1 Input 1 Input 1 
242Dnex 4-7 Input 2 Input 2 Input 2 Input 2 
282hex 8-11 Input 3 Input 3 Input 3 Input 3 

12-15 Input 4 Input 4 Input 4 Input 4 

Instance | Byte High Byte Byte Byte Low Byte 
203 hex 0-3 Input 1 Input 1 Input | Input 1 
243 hex 4-7 Input 2 Input 2 Input 2 Input 2 
283 hex 8-11 Input 3 Input 3 Input 3 Input 3 

12-15 Input 4 Input 4 Input 4 Tnput 4 
16-19 Input 5 Input 5 Input 5 Input 5 
20-23 Input 6 Input 6 Input 6 Input 6 

Instance |_ Byte High Byte Byte Byte Low Byte 
204 nex WSs) Input 1 Input 1 Input 1 Input 1 
244 nex 4-7 Input 2 Input 2 Input 2 Input 2 
284 nex xe * és ade Xe 

24-27 Input 7 Input 7 Input 7 Input 7 
28-31 Input 8 Input 8 Input 8 Input 8 

Instance Byte High Byte Byte Byte Low Byte 
20Shex 0-3 Input 1 Input 1 Input 1 Input 1 
245 hex 4-7 Input 2 Input 2 Input 2 Input 2 
285hex 2 a die aes sie 

p2ooo Input 9 Input 9 Input 9 Input 9 
36 - 39 Input 10 Input 10 Input 10 Input 10 

Instance | Byte High Byte Byte Byte Low Byte 
206hex 0-3 Input 1 Input 1 Input | Input | 
246 hex 4-7 Input 2 Input 2 Input 2 Input 2 
286 hex Se “ iyi is 8 

40 - 43 Input 11 Input 11 Input 11 Input 11 
44-47 Input 12 Input 12 Input 12 Input 12 
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Instance | Byte High Byte Byte Byte Low Byte 
20 Thee 0-3 Input 1 Input 1 Input 1 Input 1 
24T hex 4-7 Input 2 Input 2 Input 2 Input 2 
287 hex se ‘ 

48-51 Input 13 Input 13 Input 13 Input 13 
52-55 Input 14 Input 14 Input 14 Input 14 

Instance Byte High Byte Byte Byte Low Byte 
208 hex. 0-3 Input 1 Input 1 Input 1 Input 1 
248 nex 4-7 Input 2 Input 2 Input 2 Input 2 
2BBrex aS ae ie 2s a8 

56-59 Input 15 Input 15 Input 15 Input 15 
60-63 Input 16 Input 16 Input 16 Input 16 

Instance | Byte High Byte Byte Byte Low Byte 
209hex 0-3 Tnput 1 Input I Input 1 Input 1 
BAS eal || AST. Input 2 Input 2 Input 2 Input 2 
289 hex ae “i ae std = 

65 - 67 Input 17 Input 17 Input 17 Input 17 
68-71 Input 18 Input 18 Input 18 Input 18 

Instance |_ Byte High Byte Byte Byte Low Byte 
20Abex 0-3 Input 1 Input 1 Input 1 Input 1 
24 Arex 4-7 Input 2 Input 2 Input 2 Input 2 
28Abex ss ie Es ass 

72-75 Input 19 Input 19 Input 19 Input 19 
76-79 Input 20 Input 20 Input 20 Input 20 

Instance | Byte High Byte Byte Byte Low Byte 
20Brex 0-3 Input 1 Input | Input 1 Input 1 
24Bhex 4-7 Input 2 Input 2 Input 2 Input 2 
28Bhex oe i a6 a — 

88-91 Input 23 Input 23 Input 23 Input 23 
92-95 Input 24 Input 24 Input 24 Input 24 

Instance Byte High Byte Byte Byte Low Byte 
20C ex 0-3 Input 1 Input 1 Input 1 Input | 
Digan eae Input 2 Input 2 Input 2 Input 2 
28C hex & * oe re a 

104 - 107 Input 27 Input 27 Input 27 Input 27 
108 - 111 Input 28 Input 28 Input 28 Input 28 
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Instance | Byte High Byte Byte Byte Low Byte 
20D hex 0-3 Input 1 Input 1 Input 1 Input 1 
24D hex 4-7 Input 2 Input 2 Input 2 Input 2 
28Drex es i 

120 - 123 Input 31 Input 31 Input 31 Input 31 
124 - 127 Input 32 Input 32 Input 32 Input 32 


Table 6-7.25 Safety and Standard Data 32 bit Open Assembly Instances with Status 


Instance | Byte High Byte Byte Byte Low Byte 
210hex 0-3 Input 1 Input 1 Input | Input 1 
250 hex Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
290hex 4 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Input! 
Status 
Instance | Byte High Byte Byte Byte Low Byte 
Qnex 0-3 Input | Input 1 Input 1 Input 1 
51 hex 4-7 Input 2 Input 2 Input 2 Input 2 
Mex Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
32 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved Input2 Input 
Status Status 
Instance Byte High Byte Byte Byte Low Byte 
212hex 0-3 Input 1 Input | Input | Input I 
252hex 4-7 Input 2 Input 2 Input 2 Input 2 
292hex | 8-11 Input 3 Input 3 Input 3 Input 3 
PASI) Input 4 Input 4 Input 4 Input 4 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
32 Reserved | Reserved | Reserved | Reserved | Input4 Input3 Input2 Inputl 
Status Status Status Status 
Instance | Byte High Byte Byte Byte Low Byte 
213hex 0-3 Input 1 Input 1 Input 1 Input | 
PRE ley 4-7 Input 2 Input 2 Input 2 Input 2 
293 hex 8-11 Input 3 Input 3 Input 3 Input 3 
12-15 Input 4 Input 4 Input 4 Input 4 
16-19 Input 5 Input 5 Input 5 Input 5 
20 23) Input 6 Input 6 Input 6 Input 6 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
3p) Reserved | Reserved | Input6 InputS Input4 Input3 Input2 Input! 
Status Status Status Status Status Status 
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Instance | Byte High Byte Byte Byte Low Byte 
214 hex 0-3 Input 1 Input 1 Input 1 Input 1 
254nex 4-7 Input 2 Input 2 Input 2 Input 2 
294 rex ~ : 3 

24-27 Input 7 Input 7 Input 7 Input 7 
28 - 31 Input 8 Input 8 Input 8 Input 8 
Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bit1 Bitd 
32 Input8 Input7 Input6 TnputS Input4 Tnput3 Input2 Input! 
Status Status Status Status Status Status Status Status 

Instance | Byte High Byte Byte Byte Low Byte 
loner (hor Input 1 Input 1 Input 1 Input 1 
D5 ahex 4-7 Input 2 Input 2 Input 2 Input 2 
295hex a det as i ass 

32-35 Input 9 Tnput 9 Input 9 Input 9 
36 - 39 Input 10 Input 10 Input 10 Input 10 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
40 Input8 Input7 Input6 TnputS Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
41 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Inputl0 Input? 
Status Status 

Instance | Byte High Byte Byte Byte Low Byte 
216 hex 0-3 Input 1 Input | Input 1 Input 1 
256 hex 4-7 Input 2 Input 2 Input 2 Input 2 
296 ex ve Y ii see is 

40 - 43 Input 11 Input 11 Input 11 Input 11 
44-47 Input 12 Input 12 Input 12 Input 12 
Bit7 Bité Bit5 Bit4 Bit3 Bit2 Bitl Bito 
24 Input8 Input7 Input6 Input5 Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
25 Reserved | Reserved | Reserved | Reserved | Inputl2 | Inputl1 | InputlO Input9 
Status Status Status Status 

Instance | Byte High Byte Byte Byte Low Byte 
217hex 0-3 Input 1 Input 1 Input 1 Input 1 
257hex 4-7 Input 2 Input 2 Input 2 Input 2 
29Thex Ze ie 3 si sit 

48-51 Input 13 Input 13 Input 13 Input 13 
Se2 55) Input 14 Input 14 Input 14 Input 14 
Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
56 Input8 Input7 Input6 InputS Input4 Input3 Input2 Inputl 
Status Status Status Status Status Status Status Status 
57 Reserved | Reserved | Inputl4 | Inputl3 | Inputl2 | Inputil | InputlO Tnput9 
Status Status Status Status Status Status 
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Instance | Byte High Byte Byte Byte Low Byte 
218hex 0-3 Input 1 Input 1 Input 1 Input 1 
258hex 4-7 Input 2 Input 2 Input 2 Input 2 
298nex ~ ‘ 

56 - 59 Input 15 Input 15 Input 15 Input 15 
60 - 63 Input 16 Input 16 Input 16 Input 16 
Bit7 Bit6 Bits Bit4 Bit3 Bit2 Bitl BitO 
64 Tnput8 Input7 Input6 TnputS Tnput4 Tnput3 Input2 Input! 
Status Status Status Status Status Status Status Status 
65 Inputl6 | Inputl5 | Inputl4 | Inputl3 Inputl2 Inputl1 TnputlO Input9 
Status Status Status Status Status Status Status Status 
Instance | Byte High Byte Byte Byte Low Byte 

219bex 0-3 Input 1 Input 1 Input 1 Input 1 

259bex 4-7 Input 2 Input 2 Input 2 Input 2 

299 rex oe S in as ae 

65 - 67 Input 17 Input 17 Input 17 Input 17 
68-71 Input 18 Input 18 Input 18 Input 18 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
72 Input8 Input7 Tnput6 TInputS Input4 Input3 Tnput2 Input! 
Status Status Status Status Status Status Status Status 
B Inputl6 | Input! | Inputl4 | Inputi3 | Inputi2 | Inputtt | Inputio | Inputo 
Status Status Status Status Status Status Status Status 
74 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Inputl8 Input!7 
Status Status 
Instance | Byte High Byte Byte Byte Low Byte 
Die, Os Input 1 Input 1 Input | Input 1 
25Atex 4-7 Input 2 Input 2 Input 2 Input 2 
29Atex fie 2 a ee 6 
72-75 Input 19 Input 19 Input 19 Input 19 
76-79 Input 20 Input 20 Input 20 Input 20 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
80 Input8 Tnput7 Input6 TnputS Input4 Input3 Input2 Input 
Status Status Status Status Status Status Status Status 
81 Inputl6 | InputlS | Inputl4 | Inputl3 | Inputl2 | Inputl! Inputl10 Input? 
Status Status Status Status Status Status Status Status 
82 Reserved | Reserved | Reserved | Reserved | Input20 | Inputl9 | Inputl8 | Inputl7 
Status Status Status Status 
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Instance | Byte High Byte Byte Byte Low Byte 
21Bhex 0-3 Input 1 Input 1 Input 1 Input 1 
25Bhex 4-7 Input 2 Input 2 Input 2 Input 2 
29Bhex #5 zs 

88-91 Input 23 Input 23 Input 23 Input 23 
92-95 Input 24 Input 24 Input 24 Input 24 
Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
96 Input Input7 Input6 InputS Tnput4 Input3 Input2 Tnputl 
Status Status Status Status Status Status Status Status 
97 Inputl6| Input! Inputl4 Inputl3 Inputl2 Input! 1 InputlO Input9 
Status Status Status Status Status Status Status Status 
98 Input24 | Input23 Input22 Input21 Input20 Tnputl9 Input18 Inputl7 
Status Status Status Status Status Status Status Status 

Instance | Byte High Byte Byte Byte Low Byte 
21x 0-3 Input 1 Input 1 Input 1 Input 1 
25Chex 4-7 Input 2 Input 2 Input 2 Input 2 
29Chex io site 

104 - 107 Input 27 Input 27 Input 27 Input 27 
108-111 Input 28 Input 28 Input 28 Input 28 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bito 
112 | Inputs | Input? | Inputé | Inputs | Inputé | Input3 | Input2 | Inputl 
Status Status Status Status Status Status Status Status 
113 Inputl6 | InputlS Input!4 | Input!3 Input!2 Input! 1 TnputlO Input? 
Status Status Status Status Status Status Status Status 
114 Input24 | Input23 Input22 | Input21 Input20 Inputl9 Input 18 Inputl7 
Status Status Status Status Status Status Status Status 
11S Reserved | Reserved | Reserved | Reserved | Input28 Input27 Input26 Tnput25 
Status Status Status Status 

Instance Byte High Byte Byte Byte Low Byte 

21D hex 0-3 Input 1 Input 1 Input 1 Input 1 

25D hex 4-7 Input 2 Input 2 Input 2 Input 2 

29D hex 29 is 

120 - 123 Input 31 Input 31 Input 31 Input 31 
124-127 Input 32 Input 32 Input 32 Input 32 
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
128 Input8 Tnput7 Input6 TnputS Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
129 Inputl6 | InputlS Inputl4 | Inputl3 | Inputl2 Input! 1 TInputlO Input9 
Status Status Status Status Status Status Status Status 
130 Input24 | Input23 Input22 | Input21 Input20 Tnputl9 Input 18 Tnputl7 
Status Status Status Status Status Status Status Status 
131 | Input32 | Input31 | Input30 | Inpur29 | Input2s | Input27 | Input26 | Input2s 
Status Status Status Status Status Status Status Status 
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Table 6-7.26 Safety and Standard Data 32 bit Open Output Assembly Instances 


Instance | Byte High Byte Byte Byte Low Byte 
230bex. 0-3 Output 1 Output 1 Output 1 Output 1 
270 nex 
2BOnex 

Instance | Byte High Byte Byte Byte Low Byte 
2alhex 0-3 Output 1 Output 1 Output 1 Output 1 
2 hex 4-7 Output 2 Output 2 Output 2 Output 2 
2Bl hex 

Instance |_ Byte High Byte Byte Byte Low Byte 
Py Hern 0-3 Output | Output | Output 1 Output 1 
QT2bex 4-7 Output 2 Output 2 Output 2 Output 2 
2B2vex 8-11 Output 3 Output 3 Output 3 Output 3 

12-15 Output 4 Output 4 Output 4 Output 4 

Instance | Byte High Byte Byte Byte Low Byte 
233 ter 0-3 Output | Output | Output 1 Output 1 
273 hex 4-7 Output 2 Output 2 Output 2 Output 2 
2B3 hex 8-11 Output 3 Output 3 Output 3 Output 3 

12-15 Output 4 Output 4 Output 4 Output 4 
16-19 Output 5 Output 5 Output 5 Output 5 
20-23 Output 6 Output 6 Output 6 Output 6 

Instance | Byte High Byte Byte Byte Low Byte 
234 nex (es) Output 1 Output 1 Output 1 Output 1 
274 nex 4-7 Output 2 Output 2 Output 2 Output 2 

24-27 Output 7 Output 7 Output 7 Output 7 
28-31 Output 8 Output 8 Output 8 Output 8 

Instance Byte High Byte Byte Byte Low Byte 
235 hay 0-3 Output 1 Output 1 Output 1 Output 1 
275 tex. 4-7 Output 2 Output 2 Output 2 Output 2 
2B hex es a wae ats wie 

p2ooo Output 9 Output 9 Output 9 Output 9 
36 - 39 Output 10 Output 10 Output 10 Output 10 

Instance | Byte High Byte Byte Byte Low Byte 
236hex 0-3 Output | Output | Output | Output 1 
276 hex 4-7 Output 2 Output 2 Output 2 Output 2 
2BGnex ee es es sas a 

40 - 43 Output 11 Output 11 Output 11 Output 11 
44-47 Output 12 Output 12 Output 12 Output 12 
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Instance Byte High Byte Byte Byte Low Byte 
D3iThex 0-3 Output | Output 1 Output 1 Output 1 
27 Tex 4-7 Output 2 Output 2 Output 2 Output 2 
2B7 nex = é 

48-51 Output 13 Output 13 Output 13 Output 13 
52-55 Output 14 Output 14 Output 14 Output 14 

Instance Byte High Byte Byte Byte Low Byte 
238hex 0-3 Output | Output 1 Output 1 Output 1 
278bex 4-7 Output 2 Output 2 Output 2 Output 2 
2BBjex ee a as es Pr 

56-59 Output 15 Output 15 Output 15 Output 15 
60 - 63 Output 16 Output 16 Output 16 Output 16 

Instance | Byte High Byte Byte Byte Low Byte 
239 hex 0-3 Output 1 Output 1 Output 1 Output 1 
279 hex 4-7 Output 2 Output 2 Output 2 Output 2 
2Bpex oe sis ae oid 33 

65 - 67 Output 17 Output 17 Output 17 Output 17 
68-71 Output 18 Output 18 Output 18 Output 18 

Instance |_ Byte High Byte Byte Byte Low Byte 
23Atex 0-3 Output | Output 1 Output 1 Output 1 
27Abex 4-7 Output 2 Output 2 Output 2 Output 2 
2BAtex Ss es ae a = 

72-75 Output 19 Output 19 Output 19 Output 19 
76-79 Output 20 Output 20 Output 20 Output 20 

Instance | Byte High Byte Byte Byte Low Byte 
23Bhex 0-3 Output | Output 1 Output | Output | 
27Bhex 4-7 Output 2 Output 2 Output 2 Output 2 
2BBhex aa a 156 re ssh 

88-91 Output 23 Output 23 Output 23 Output 23 
92-95 Output 24 Output 24 Output 24 Output 24 

Instance Byte High Byte Byte Byte Low Byte 
23Chex 0-3 Output | Output 1 Output 1 Output 1 
27C hex 4-7 Output 2 Output 2 Output 2 Output 2 
2BChex 5a oe se ne BA 

104 - 107 Output 27 Output 27 Output 27 Output 27 
108 - 111 Output 28 Output 28 Output 28 Output 28 
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Instance | Byte High Byte Byte Byte Low Byte 
23Dhex 0-3 Output 1 Output 1 Output 1 Output 1 
27D hex 4-7 Output 2 Output 2 Output 2 Output 2 
2BDhex = i 
120 - 123 Output 31 Output 31 Output 31 Output 31 
124 - 127 Output 32 Output 32 Output 32 Output 32 
Table 6-7.27 Safety and Standard Data Open Assembly Instances with Status Only 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2C0 hex 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Input] 
Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bit1 Bit0 
2CIhex 0 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Input2 Input! 
Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bito 
2C2nex 0 Reserved | Reserved | Reserved | Reserved | Input4 Input3 Input2 Inputl 
Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2C3hex 0 Reserved | Reserved Input6 Inputl5S Input4 Input3 Input2 Input! 
Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2C4 nex 0 Input8 Input7 Input6 Input15 Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
2CShex 0 Input8 Input7 Input6 Input15 Input4 Input3 Input2 Input1 
Status Status Status Status Status Status Status Status 
il Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | InputlO Input9 
Status Status 
Instance | Byte Bit7 Bit6é BitS Bit4 Bit3 Bit2 Bit1 Bito 
2C6 hex 0 Input8 Input7 Input6 Inputl5 Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
1 Reserved | Reserved | Reserved | Reserved | Inputl2 Input! 1 Inputl0 Input9 
Status Status Status Status 
Instance | Byte Bit7 Bit6é BitS Bit4 Bit3 Bit2 Bitl Bit 
2CT rex 0 Input8 Input7 Input6 Inputl5S Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
1 Reserved | Reserved | Inputl4 Inputl3 Inputl2 Input! 1 InputlO Input9 
Status Status Status Status Status Status 
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Instance | Byte Bit7 Bit6é BitS Bit4 Bit3 Bit2 Bitl Bit 
2C8hex 0 Input8 Input7 Input6 InputlS Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
i Inputl6 Inputl5 Inputl4 Inputl3 Inputl2 Input 1 InputlO Input9 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6é BitS Bit4 Bit3 Bit2 Bitl Bit 
200. 0 Input8 Input7 Input6 Input!S Tnput4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
il Inputl6 Inputl5 Inputl4 Inputl3 Inputl2 Input 1 InputlO Input9 
Status Status Status Status Status Status Status Status 
2 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Inputl8 Tnput7 
Status Status 
Instance | Byte Bit7 Bit6 Bits Bit4 Bit3 Bit2 Bitl Bito 
2CAnex 0 Input8 Input7 Input6 Inputl5S Input4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
il Inputl6 InputlS Inputl4 TInputl3 Inputl2 Input! 1 InputlO Tnput9 
Status Status Status Status Status Status Status Status 
2 Reserved | Reserved | Reserved | Reserved | Input20 Inputl9 Input !8 Inputl7 
Status Status Status Status 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bito 
2CBhex 0 Input8 Input7 Input6 Inputl5S Tnput4 Input3 Input2 Input! 
Status Status Status Status Status Status Status Status 
it Inputl6 Input!5 Inputl4 Inputl3 Inputl2 Input! 1 TInputlO Input9 
Status Status Status Status Status Status Status Status 
2 Input24 Input23 Input22 Input21 Input20 Inputl9 Input18 Input!7 
Status Status Status Status Status Status Status Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl BitO 
2CCie, 0 Tnput8 Tnput7 Input6 Inputl5S Tnput4 Input3 Tnput2 Input! 
Status Status Status Status Status Status Status Status 
il Inputl6 Tnput!5 Inputl4 Inputl3 Inputl2 Input! 1 Inputl0 Input9 
Status Status Status Status Status Status Status Status 
2 Input24 Input23 Input22 Input21 Input20 Inputl9 Input!8 Inputl7 
Status Status Status Status Status Status Status Status 
3 Reserved | Reserved | Reserved | Reserved | Input28 Input27 Input26 Input25 
Status Status Status Status 
Instance | Byte Bit7 Bit6 Bits Bit4 Bit3 Bit2 Bitl BitO 
2CDiex 0 Input8 Input7 Input6 Input!5 Input4 Input3 Input2 Input! 
Status Status Status: Status Status Status Status Status 
1 Inputl6 | Inputl5 Inputl4 | Inputl3 | Input!2 | Inputl! Input 10 Input? 
Status Status Status Status Status Status Status Status 
2 Input24 | Input23 | Tnput22 | Input21 | Input20 | Inputio | Mmputis | Iputt7 
Status Status Status Status Status Status Status Status 
3 Input32 Input31 Tnput30 Input29 Input28 Input27 Input26 Tnput25 
Status Status Status Status Status Status Status Status 
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Safety Analog I/O Device, Type: 2Attex 


Instance | Byte Bit7 Bit6é BitS Bit4 Bit3 Bit2 Bit1 Bito 
WDOhex 0 Fault Reason 1 

Instance | Byte Bit7 Bit6 Bit5 Bitd Bit3 Bit2 Bitl BitO 
2D hex 0 Fault Reason 1 
iV Fault Reason 2 

Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bit 
2D2hex 0 Fault Reason 1 
a Fault Reason 3 

Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bito 
2D3 hex 0 Fault Reason 1 
a! Fault Reason 6 

Instance | Byte Bit7 Bit6é BitS Bit4 Bit3 Bit2 Bitl Bit 

2D4bex 0 Input8 Input7 Input6 Input15 Input4 Input3 Input2 Input! 

Status Status Status Status Status Status Status Status 
0 Fault Reason | 
2 Fault Reason 8 

Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bitd 
2D5 hex 0 Fault Reason 1 
9 Fault Reason 10 

Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bitd 
2D6 nex 0 Fault Reason 1 
ily Fault Reason 12 

Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bit 
2DThex 0 Fault Reason 1 
13 Fault Reason 14 

Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bit0 
2D8hex 0 Fault Reason 1 
15 Fault Reason 16 
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Safety Analog I/O Device, Type: 2Attex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 BitO 
Dex 0 Fault Reason 1 
ig Fault Reason 18 
Instance | Byte Bit7 Bit6é BitS Bit4 Bit3 Bit2 Bitl Bitd 
2DAtex 0 Fault Reason 1 
ihe) Fault Reason 20 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 BitO 
2DBhex 0 Fault Reason 1 
23 Fault Reason 24 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bito 
2DChex 0 Fault Reason | 
27 Fault Reason 28 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit 
2DDpex 0 Fault Reason | 
31 Fault Reason 32 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2EOnex 0 Fault Reason 1 
ik Alarm/Warning Reason1 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2EThex 0 Fault Reason 1 
il Fault Reason 2 
2 Alarm/Warning Reason 1 
6] Alarm/Warning Reason 2 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
QE 2hex 0 Fault Reason 1 
ai Fault Reason 6 
4 Alarm/Warning Reason | 
7 Alarm/Warning Reason 4 
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Safety Analog I/O Device, Type: 2Attex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bit 
2E 3 ix 0 Fault Reason 1 
A Fault Reason 6 
6 Alarm/Warning Reason 1 
ili) Alarm/Warning Reason 6 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bit 
p) 0 Fault Reason 1 
7 Fault Reason 8 
8 Alarm/Warning Reason 1 
15 Alarm/Warning Reason 8 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2EShex 0 Fault Reason 1 
9 Fault Reason 10 
10 Alarm/Warning Reason | 
17 Alarm/Warning Reason 10 
Instance | Byte Bit7 Bit6é Bit Bit4 Bit3 Bit2 Bitl Bitd 
2E6 hex 0 Fault Reason 1 
ili Fault Reason 12 
12 Alarm/Warning Reason 1 
21 Alarm/Warning Reason 12 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
2EThex 0 Fault Reason | 
13 Fault Reason 14 
14 Alarm/Warning Reason 1 
27 Alarm/Warning Reason 14 
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Safety Analog I/O Device, Type: 2Attex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl BitO 
2EBhex 0 Fault Reason 1 
15 Fault Reason 16 
16 Alarm/Warning Reason 1 
31 Alarm/Warning Reason 16 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bit 
2EQnex 0 Fault Reason 1 
17 Fault Reason 18 
18 Alarm/Warning Reason 1 
33 Alarm/Warning Reason 18 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2EAnex 0 Fault Reason 1 
19 Fault Reason 20 
20 Alarm/Warning Reason 1 
BS) Alarm/Warning Reason 20 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
2EBnex 0 Fault Reason 1 
23 Fault Reason 24 
24 Alarm/Warning Reason 1 
47 Alarm/Warning Reason 24 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bit 
QEC 0 Fault Reason | 
27 Fault Reason 28 
28 Alarm/Warning Reason 1 
55 Alarm/Warning Reason 28 
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Safety Analog I/O Device, Type: 2Attex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bito 
2EDiex 0 Fault Reason 1 
31 Fault Reason 32 
32 Alarm/Warning Reason 1 
63 Alarm/Warning Reason 32 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bit1 Bitd 
2FObex 0 Reserved | Reserved | Reserved | Output] | Reserved | Reserved | Reserved | Output 
Monitor Status 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bit1 Bit 
2F nex 0 Reserved | Reserved | Output2 | Output! | Reserved | Reserved | Output2 | Output! 
Monitor | Monitor Status Status 
Instance | Byte Bit7 Bit6 Bits Bit4 Bit3 Bit2 Bitl Bitd 
QF 2hex 0 Output4 Output3 | Output2 | Output] | Output4 | Output3 | Output2 | Output! 
Monitor Monitor | Monitor | Monitor Status Status Status Status 
Instance | Byte Bit7 Bit6é Bits Bit4 Bit3 Bit2 Bitl Bitd 
Dire 0 Reserved | Reserved | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status 
1 Reserved | Reserved | Output6 | Outputs | Output4 | Output3 | Output2 | Output! 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
2F4nex 0 Outputs Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
1 Output’ Output7 | Output6 | OutputS | Output4 Output3 Output2 Output! 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bit 
2F5 cx 0 Outputs | Output7 | Outputs | Outputs | Outputd | Output3 | Output2 | Outputt 
Status Status Status Status Status Status Status Status 
il Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Outputl0 | Output9 
Status Status 
2 Output8 Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
& Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Outputl0 | Output9 
Monitor | Monitor 
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Safety Analog I/O Device, Type: 2Attex 


Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
2F6 nex 0 Outputs Output? | Output6 | Outputs | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
il Reserved | Reserved | Reserved | Reserved | Outputl2 | Outputl1 | Outputl0 | Output9 
Status Status Status Status 
Ds Output8 Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
4 Reserved | Reserved | Reserved | Reserved | Outputl2 | Outputl1 | Outputl0 | Output? 
Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6é Bit5 Bit4 Bit3 Bit2 Bitl Bit 
BEE 0 Outputs Output? | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
il Reserved | Reserved | Outputl4 | Outputl3 | Outputl2 | Outputl! | OutputlO | Output9 
Status Status Status Status Status Status 
2 Output8 Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
a Reserved | Reserved | Outputl4 | Outputl3 | Outputl2 | Outputl! | OutputlO | Output? 
Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bit 
2F8hex 0 Outputs Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
1 Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl1 | OutputlO | Output9 
Status Status Status Status Status Status Status Status 
2 Output8 Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
a Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl!2 | Output! | OutputlO | Output9 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Instance | Byte Bit7 Bit6é Bit5 Bit4 Bit3 Bit2 Bitl Bit 
2FO nc. 0 Output Output? | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
1 Outputl6 | OutputlS | Outputl4 | Outputl3 | Output!2 | Outputl1 | OutputlO | Output9 
Status Status Status Status Status Status Status Status 
2 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Outputl8 | Outputl7 
Status Status 
al Outputs Output? | Output6 | Outputs | Output4 | Output3 | Output2 | Output! 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
4 Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl! | OutputlO | Output9 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
5 Reserved | Reserved | Reserved | Reserved | Reserved | Reserved | Output!8 | Outputl7 
Monitor | Monitor 
— 6-87 — 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 6: Device Profiles 


Safety Analog I/O Device, Type: 2Attex 


Instance | Byte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bitl Bitd 
2FAnex 0 Outputs Output? | Output6 | Outputs | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 

1 Outputl6 | OutputlS | Outputl4 | Outputl3 | Output!2 | Output! | OutputlO | Output9 

Status Status Status Status Status Status Status Status 
2 Reserved | Reserved | Reserved | Reserved | Output20 | Outputl9 | Output!8 | Output!7 

Status Status Status Status 

3 Output8 Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 

Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 

4 Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl! | OutputlO | Output9 

Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
5 Reserved | Reserved | Reserved | Reserved | Output20 | Outputl9 | Outputl8 | Outputl7 

Monitor | Monitor | Monitor | Monitor 

Instance | Byte Bit7 Bité BitS Bit4 Bit3 Bit2 Bitl Bitd 
2FBhex 0 Output8 Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 

1 Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl!2 | Outputl1 | OutputlO | Output9 

Status Status Status Status Status Status Status Status 
2 Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Outputl8 | Output!7 

Status Status Status Status Status Status Status Status 

3 Output’ Output7 | Output6 | OutputS | Output4 Output3 Output2 Output! 

Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 

4 Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl1 | OutputlO | Output9 

Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
5 Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Outputl8 | Outputl7 

Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 

Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bitd 
2ECiex 0 Outputs Output? | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 

1 Outputl6 | OutputlS | Outputl4 | Outputl3 | Output!2 | Outputl1 | OutputlO | Output9 

Status Status Status Status Status Status Status Status 
2 Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Outputl8 | Outputl7 

Status Status Status Status Status Status Status Status 
3 Reserved | Reserved | Reserved | Reserved | Output28 | Output27 | Output26 | Output25 

Status Status Status Status 

4 Output8 Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 

Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 

5 Outputl6 | OutputlS | Outputl4 | Outputl3 | Output!2 | Output] | OutputlO | Output9 

Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
6 Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Outputl8 | Outputl7 

Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
7 Reserved | Reserved | Reserved | Reserved | Output28 | Output27 | Output26 | Output25 

Monitor | Monitor | Monitor | Monitor 
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6-7.8 


Safety Analog I/O Device, Type: 2Attex 


Instance | Byte Bit7 Bit6 BitS Bit4 Bit3 Bit2 Bitl Bito 
2FDhex 0 Outputs Output? | Output6 | Outputs | Output4 | Output3 | Output2 | Output! 
Status Status Status Status Status Status Status Status 
il Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl2 | Outputl1 | OutputlO | Output9 
Status Status Status Status Status Status Status Status 
2 Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Outputl8 | Output!7 
Status Status Status Status Status Status Status Status 
ey Output32 | Output31 | Output30 | Output29 | Output28 | Output27 | Output26 | Output25 
Status Status Status Status Status Status Status Status 
4 Output8 Output7 | Output6 | OutputS | Output4 | Output3 | Output2 | Output! 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
3 Outputl6 | OutputlS | Outputl4 | Outputl3 | Outputl!2 | Outputl1 | OutputlO | Output9 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
6 Output24 | Output23 | Output22 | Output21 | Output20 | Outputl9 | Outputl8 | Outputl7 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
2 Output32 | Output31 | Output30 | Output29 | Output28 | Output27 | Output26 | Output25 
Monitor Monitor | Monitor | Monitor | Monitor | Monitor | Monitor | Monitor 
Mapping I/O Assembly Data Attribute Components 
The following table indicates the I/O assembly Data attribute mapping for the Safety Analog 


W/O device for the input assemblies wit 


h safety input data and no safety status. 


Table 6-7.28 Instance Numbers 180 -18Dyex, 1C0 -1CDypx, 200 -20D px, 240 -24Dyex, 280 -28Duex 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety Input N Safety Analog Input 49hex N Safety Analog Input | 2 
Point Value 


The following table indicates the I/O assembly Data 


I/O device for the input assemblies witl 


h safety input 


attribute mapping for the Safety Analog 
data and safety input status. 


Table 6-7.29 Instance Numbers 190 -19Dyex, 1D0 -1DDyex, 210 -21Dyex, 250 -25D yx, 290 -29Dyex 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety Input N Safety Analog Input 49hex N Safety Analog Input | 2 
Point Value 
Safety Input Status | Safety Analog Input 49hex N Input Point Status 5 


The following tabl 


le indicates the I/O assembly Data 


attribute mapping for the Safety Analog 
I/O device for the output assemblies with safety output data. 


Table 6-7.30 Instance Numbers 1B0 -1BDyrx, 1F0 -1FDyex, 230 -23D yx, 270 -27D px, 2B0 -2BDurx 


Data Component Class Instance Attribute 
Name Name Number Number Name Number 
Safety Output N Safety Analog Output | TBDhex N Safety Output Value | TBD 
Point 
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Safety Analog I/O Device, Type: 2Attex 
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7-1 


7-11 


7-111 


7-1.1.2 


Safety Configuration Process 


Introduction to Safety Configuration 


The purpose of this section is to identify the TUV certified Safety Network Configuration 
process and the configuration data flows through the safety system. This section defines the 
system and the software requirements of the Safety Network Configuration interface and how 
data is protected to ensure the safety system meets SIL3. 


The configuration process is comprised of two parts: 1) download and 2) testing and 
verification. 


Download Process: 
During the download portion of the configuration process the configuration data is transferred 
from one of the following two sources: 


1. The Safety Network Configuration Tool (SNCT) to the device being configured 
2. From the originator to the target device. 


Verification Process: 

During the verification stage the user will functionally test the device in the system, and 
visually verify that the correct configuration data has been transferred to the device being 
configured. 


Together the protections in these two parts ensure that devices are suitably configured for use 
in a SIL3 environment. 


Configuration Goals 
Goal Description 


Goal | To ensure with high integrity that the intended configuration created by the 
user with the software was correctly sent to and saved in the safety device. 


Goal 2 To have a common download process that is the same for the transfer of 
configuration data to all safety devices. 


Goal 3 To have a common download process that is the same for the transfer of 
configuration data from a software tool or an originating device during 
configuration. 


Goal 4 To ensure with SIL3 integrity that a target device has the intended 
configuration prior to opening a safety connection. The measures used during 
configuration download should be reused in the safety connection 
establishment process. 


Goal 5 To ensure unique identification of configuration with or without data being 
included within a connection establishment 


Configuration Overview 


Safety Configuration begins with the downloading of configuration data into a safety device. 
Figure 7-1.1 shows the possible configuration data transfers into safety devices. The numbers 
in the figure are references to the discussion numbering below. 
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Figure 7-1.1 Configuration Data Transfers 


He 6. Originator to Target \ 
4 Download Ne 
j ] 
> 
Originator 7. SafetyOpen | 


Configuration 


Device (2) ‘ Target Device (3) 


The devices involved in the configuration process are shown in Figure 7-1.1. 


The SNCT (1) Safety Network Configuration Tool and the process described in this 
specification allows this tool to be non-safety critical. 

The Originator (2) is a device that is capable of configuring Target devices (3) while 
initiating connections to them. Because these devices can hold configuration data for 
Targets (for targets that are not configured by the SNCT directly), they have additional 
procedures to complete the configuration process. 

The Target device (3) is one that can be either configured directly by the SNCT or can be 
configured by an Originator (2) owner. The ownership concept plays an important role in 
assuring the integrity of “originator configured” targets. 


There are two basic configuration procedures (refer to Figure 7-1.1) 


SNCT-to-Originator (flow 4) an 


SNCT-to-Target (flow 5). This procedure is one that 


configures a single device and these devices hold no configuration data for other devices. 


SNCT-to-Originator-to-Target (fl 


low 4 plus flow 6 or 7). This special procedure is for 


configuring an originator device that holds configuration data for a target. 

Flow 6 is a procedure that duplicates the sequence of operations that would otherwise be 
done in flow 5. 

Flow 7 is a procedure by which t 
SafetyOpen. 

There are two ways that a replacement device can be reconfigured from the originator 
Flow 6 is a procedure that duplicates the sequence of operations that would otherwise be 
done in flow S. 

Flow 7 is a procedure by which t 
SafetyOpen. 


e configuration is performed as part of the processing of a 


e configuration is performed as part of the processing of a 
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7-1.1.3 


User Configuration Guidelines 


This section describes user configuration guidelines that assure a CIP safety system is properly 
configured and protected. These guidelines are used to define the safety manual requirements. 


1. 


The CIP safety system user must assure that SNCT-configured-devices (2) are locked after 
verification (related requirements SRS50 & SRS51). 


SRS202 Devices that can be configured via the SNCT interface shall include a safety 
manual advisory that instructs the user to lock the device after verification has been 
completed. 


he CIP safety system user must assure that all originator-configured-devices (3) have 
ownership (7) assigned to the intended originator. (related requirements SRS92 & SRS44) 


SRS203 Devices that can be configured by a Type 1 SafetyOpen shall include a safety 
manual advisory that instructs the user to verify that all originator-configured safety 
levices have their ownership assignments as part of the final verification process. 


The user must visually confirm (4) the sent configuration data and confirm it was 
lownloaded correctly (related requirements SRS38). 


SRS204 All CIP safety devices shall include a safety manual advisory that instructs the 
user to visually verify that all configuration data was downloaded correctly. 


The user must functionally test their application (related requirements SRS42 & SRS43). 


Refer to section 7-1.5, Verification Process for related safety manual requirements. 


The user must assure the SCID (5) check by target and originator is done (related 
requirements SRS44). 


Refer to section 7-1.5, Verification Process for related safety manual requirements. 


Figure 7-1.2 Protection Measures in Safety Devices 
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7-1.1.4 


Configuration Process SIL3 Justification 


The CIP safety device being downloaded has safety measures defined which ensures integrity 
of data and data transfers as specified by IEC61508 SIL3. 


The SNCT on the other hand, will not be certified due to the limitations of personal computer 
hardware, the operating system utilized, and the development tools. Because of these factors, 
the techniques employed to configure a safety device require that the safety device and user 
procedures, not the workstation software, enforce the protection measures. 


SIL3 integrity is achieved by meeting the following requirements: 


e SRS36 A receiving SIL3 device shall calculate a SCCRC with SIL3 integrity and compare 
it to the SCCRC within the SCID . 

SRS37 For Type 1 configured or tool configured devices, configuration validation of the 
downloaded safety-relevant data from the software (or originator) shall be performed with 
SIL3 integrity . 

SRS38 When a SIL3 device is configured directly from a workstation, the device safety 
manual shall instruct the user to compare the transferred SCID and configuration data with 
the SCID and configuration data originally viewed in the workstation. 

SRS39 The SNCT software shall provide a facility to allow the user to confirm downloaded 
configurations are correct. 

SRS40 SIL3 devices shall store/restore its configuration data with SIL3 integrity . 

e SRS41 SIL3 devices shall handle all device state transitions with SIL3 integrity 


Sub-systems that are required to be examined and certified to SIL3 


e Target device configuration processing 
e Target device configuration storage 
Target device configuration validation 
Target device modes 


Sub-systems that are not required to be certified SIL3 


e Explicit messaging 
Justification: The explicit messaging subsystem is simply a means of transferring the data, 
all integrity measures are performed by other system components and any errors such as 
corruption or loss of messages will be detected by the safety measures. 

e Software User Interface 
Justification: The software interface is a means to display and enter data that will later be 
confirmed by other means. In itself, it does not require SIL3 integrity, but it will be used in 
conjunction with a diverse read back and display mechanism to form a high integrity 
function. 

e Software Tool configuration storage 
Justification: Any configuration data is stored with a safety related CRC that is verified to 
match the safety related CRC in the device. Any corruption of the data will be detected by 
the device’s SIL3 CRC checking process. 
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7-1.2 


7-1.2.1 


7-1.2.2 


Device Functions for Tool Configuration 


The process by which the SNCT interacts with originators and targets are controlled by 
facilities defined in the Safety Supervisor Object. Features such as Password protection and the 
Configuration Lock attribute combine to provide security for this interface. Since the Safety 
Supervisor is provided in the baseline profile (refer to Chapters 5 & 6) for both safety targets 
and originators, the interface details are common. This section will define these features and 
how they are used by the SNCT. 


Password Security 
The SNCT interface defines the following functions to optionally provide password security: 


e Password functionality added 
e¢ SRS17 Support for one password shall be implemented by devices supporting the SNCT 
interface 
e Passwords submitted to devices supporting the SNCT interface shall be values obtained 
from running the encryption algorithm defined in Section 7-2.1.3 and Appendix E. 
e¢ SRS20 The default password value in devices supporting the SNCT interface shall be 
zero 
¢ SRS21 Software shall transparently insert “zero” in all services which require one 
until a user sets it to something different 
e¢ SRS22 The SNCT interface shall support a Password service to set passwords which takes 
2-password parameters; Old PW and New PW 
e SRS23 The SNCT interface shall provide a Reset Password service which takes a vendor 
specific field to reset the password 
e Each vendor shall choose a method to reset passwords and instruct the user what to fill in 
to cause the device to reset the password. The software shall only insert whatever value 
the user enters into the reset field (refer to the Reset_Password service in the Safety 
Supervisor object definition in Chapter 5). 
e The safety supervisor commands that have a password parameter define the processing 
requirements and error responses for these parameters. 


SNCT Interface Services 

e SRS24 The SNCT interface shall provide a Configure Request service which requires 
password, TUNID, and OUNID to execute 

© SRS130 In the SNCT interface, an unowned device shall capture the OUNID as the device 
owner when the first Configure_Request is received. 

e SRS26 The SNCT interface shall provide a Validate Configuration service which requires 
the SCID, SCCRC, and the SCTS to execute . 

e SRS131 The SNCT interface shall provide an Apply service that causes the device to save 
the configuration to NV memory. 

e SRS27 The SNCT interface shall provide a special Reset service which requires the 
password and TUNID to execute and supports the 2 common Reset types along with one 
that can reset to the default but preserve the password . 

e SRS28 The SNCT interface defines an optional a Mode Change service which, if 
implemented, shall require a password to execute . 
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7-1.2.3 


7-1.2.3.1 


Configuration Lock 


The SNCT interface defines the following functions for Configuration Lock. Its intent is to 
provide a way for the user to flag that a tool-generated configuration has been tested and 
verified as valid. From that point, the signature (SCID) reflects a verified configuration. 


e SRS25 The SNCT interface shall provide a Configuration Lock service which requires the 
password and TUNID to execute 

e SRS132 The SNCT Configuration Lock Attribute shall have a default value of “Unlocked” 

e SRS31 Safety devices which support the SNCT interface shall require that the 
“Configuration Lock” attribute be cleared before any command to change a safety device to 
the Configure State (Configure_Request) will be accepted. 


The Configuration Lock has two purposes 


e Serves to indicate that the user has tested and confirmed the Tool-based configuration in this 
device is correct. 

e “Tool Only” mode requirement. SRS32 When the Configuration Lock attribute is set, the 
device shall reject any Type 1 Safety Open messages. 


These two features make it clear that for the SNCT to configure any safety node, it shall 
support features to set and clear the Configuration Lock attribute, and shall present the proper 
password to do so. These features are illustrated in the sequence diagram shown in Figure 7- 
1.5. 


Effect of Configuration Lock on Device Behavior 


Figure 7-1.3 shows the effect that the “configuration locked” condition has on the ability of a 
device to be configured; there are requirements defined in the Safety Supervisor object that 
cause safety devices to reject all attempts to change a locked configuration. 
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Figure 7-1.3 Configuration, Testing and Locked Relationships. 
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Table 7-1.1 shows the effect that ownership has on a device’s ability to be configured. It 
shows that owned devices can only be Type 1 configured by the originator that has the owner 
UNID. A locked device can never be configured regardless. 


Table 7-1.1 Configuration Owner Control vs. Device State 


Ownership Configure mode Execute/Idle Mode Execute/Idle Mode 
Rules Unlocked Locked 
Configuration | Tool configuration Tool configuration No Tool configuration, 
Un-owned or or No Type 1 accepted 
Type | acceptance by anyone Type | acceptance by 
anyone 
Originator Tool configuration No Tool configuration | No Tool configuration, 
Owned or (must reset first) No Type | accepted 


Typel by owner only Or 


Typel by owner only 


Software Tool | Tool configuration only Tool configuration No Tool configuration, 
Owned No Type I accepted only No Type | accepted 
No Type | accepted 
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7-1.2.4 


7-1.2.5 


7-13 


7-1.3.1 


Configuration Ownership 


The SNCT interface defines functionality for handling the configuration owner identifier for a 
device. This function has been defined to allow a device to provide exclusive configuration 
rights to a particular configuration source. The source could also be assigned exclusively to a 
configuration tool. The following functions are provided: 


¢ Configuration UNID attribute 
e The default is to allow any device to be an owner (refer to SRS70 & SRS134) 
e Device are required to capture the first configuration source as the owner (refer to 
SRS205) 
e Attributes and services in the Safety Supervisor are defined which allow Tools to be the 
exclusive configuration source 
e Even though an owner has been assigned as a configuration source, the SNCT tool has the 
ability to override a configuration. The SNCT shall provide protection measures to assure 
the user cannot perform an override without warnings and the proper password. 


Configuration Mode 


SRS136 All safety devices shall support a non-volatile configuration mode, this means that 
once a device is commanded to enter the configuration mode it shall remain in the 
configuration mode until the configuration is successfully validated. 


Measures Used To Ensure Integrity of Configuration Process 


This section describes the various protections that ensure the integrity of the download process. 
This section also identifies the portions of the system supporting the download process that are 
required to be certified to a SIL3 level. 


Safety Configuration Identifier (SCID) 


In safety systems it is necessary to clearly identify the configuration. The identification is used 
during several operations: 


Download from tools —This gives the user the ability to check that the tool and device agree on 
the information downloaded. 


Device Replacement — If the tool is used for device replacement, the user has the ability to 
verify that the configuration is the correct one to download. If the originator is used to 
automatically reconfigure a device, the SCID is used to indicate that a reconfiguration is 
necessary and ensure the integrity of the operation 


Connection Establishment - The originator and target use the SCID to ensure that both devices 
are using the same configuration. 


The SCID is a concatenation of the SCTS and the SCCRC described in Section 7-1.3.3 and 
Section 7-1.3.2 respectively. 
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7-1.3.1.1 


7-1.3.2 


7-1.3.3 


7-1.3.4 


7-1.3.5 


Originator and Target SCID Coverage 


When originators are used to configure targets, Figure 7-1.4 illustrates how the SCIDs provide 
coverage of the various configurations. The SCID for targets that are configured by originators 
are not calculated in the originators, the calculation is performed in the workstation. The target 
configurations are protected by their respective SCIDs. 


Figure 7-1.4 Originator's Configuration Data 


Target 1 Config 


Target 2 Config 


Target 3 Config 


Safety Configuration CRC (SCCRC) 


This is a CRC that covers the device configuration data that is contained in a SafetyOpen. It is 
part of the SCID for the device. The SCCRC is described in Chapter 2, Section 2-3.1.1. 


Safety Function — The SCCRC is used to ensure the correctness of the safety application 
data. 


Safety Configuration Timestamp (SCTS) 


The Safety Configuration Time Stamp is a safety related signature that identifies the revision of 
the device configuration contained in either a Safety Open or in a safety device. It is part of the 
SCID for the device configuration. Refer to FRS162 and Chapter 2 Section 2-3.1.1 


Safety Function — The SCTS is used to ensure the uniqueness of the safety application 
data. 


System-Wide Unique "Safety Network Number" (SNN) 


The Safety Network Number uniquely identifies a network across all networks in the safety 
system. The end user is responsible for assigning a unique number to each safety network or 
safety sub-net within a system. Refer to FRS162 and Chapter 2 Section 2-3.1.1 


Safety Function — The UNID is used to uniquely identify originators and/or targets during 
the connection establishment process 


System-Wide "Unique Node Identifier" (UNID) 


Uniquely identifies a node across all networks in the safety system. This value is made up of 
the Safety Network Number (SNN) and the Node Address of the device. This value is a 
structure consisting of the 6-octet SNN and the 4-octet Node Address. The 4-octet node 
address is sized to accommodate all forms of CIP network addresses. 
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7-1.3.6 


struct UNID 

{ 
S_SNN SNN; 
UDINT MACID; 


}; 
MACIDs smaller than 4-octets (i.e. DeviceNet) shall be aligned to the least significant octet in 
little endian order. The unused octets shall be zero filled. 


Safety Function — The UNID is used to uniquely identify originators and/or targets during 
the connection establishment process 


Other uses of UNID: 
TUNID = Target's Unique Network Identifier 
Safety Function — Identifies the target in the SafetyOpen & Configuration mode message 
OUNID = Originator's Unique Network Identifier 
Safety Function — Identifies the originator in the SafetyOpen. 
OCPUNID = Output Connection Point Owning UNID 
Safety Function — Identifies the owner of the output connection in the target. Set to the 
OUNID of the originator in the SafetyOpen that obtains ownership of the output connection 
point. Used to prevent an unauthorized originator to obtain ownership of an output 
connection point 


CFUNID = Configuration Owning UNID 


Safety Function — Identifies the owner of the safety configuration in the target, this should 
be equal to the OUNID in normal operation. This is set to the OUNID of the originator in 
the SafetyOpen that includes configuration data and is used to prevent an unauthorized 
originator from modifying the configuration. 


Connection Parameters CRC (CPCRC) 


The Connection Parameter CRC is a safety related CRC covering the CIP connection 
establishment data in the Safety Open. This CRC will also cover the additional parameters 
required by the safety protocol. The CRC is defined in Appendix E 


Safety Function — The CPCRC is used to ensure the integrity of the connection data contained 
within the Safety Open. 
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7-1.4 Download Process 


The safety download process ensures that the configuration data is transferred with high 
integrity from the SNCT or the Originator to the device being configured. At the successful 
completion of the download process the configuration is considered valid. There are two 
download processes used with safety devices: 


e SNCT downloads to originators and targets 
e Originator downloads to targets using a Type 1 SafetyOpen 


The following sections will describe the details of the processes that are used for the download 
of safety devices. 
7-1.4.1 SNCT download to originators and targets 


Figure 7-1.5 show the process of downloading a safety device from the SNCT. The download 
process between the SNCT and the Configured Device assures that the data is instantiated in 
the Configured Device’s memory with high integrity. 


Figure 7-1.5 SNCT to Device Download Process 
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7-1.4.1.1 


7-1.4.2 


SNCT to Device Download Process Steps 
1. Clear Configuration Lock Attribute 

a. Device: Configuration Lock Attribute cleared. 

2. Enter configuration state with password, TUNID, OUNID 

a. Device: No safety I/O connections can be active. 

b. Device: Device saves Config mode to NV storage 
e Until “Validate” & “Apply”, power cycles go back to config mode 

3. Transfer of configuration data 

a. Tool: Calculate “proposed SCCRC” for data (SCCRC part of SCID) 

b. Device: SRS138 Any explicit messages are allowed to set configuration in device, but 
device shall only accept safety-related explicit messages over the connection that put it 
into the configuration mode. 

4. Validate configuration data 

a. Tool: Send Validate_Request with SCID (which contains proposed SCCRC) 

b. Device: Analyze configuration data 

c. Device: Calculates SCCRC value and compares to “proposed SCCRC” 

d. Device: send SCID in Validate_Reply 

e. Tool: Compares returned SCCRC to “proposed SCCRC” 

5. Apply Configuration 

a. Device: Save configuration to NV storage with SCID 

b. Device: Mark configuration as valid. 

c. Device: Set mode to Idle 

d. Tool: Capture and store the SCID with the configuration file. 


SNCT Downloads to Originators which do Type 1 Target Configuration 


Figure 7-1.6 show the process by which Originators are initially configured and how the Type 
1 Safety Open is used to download Target devices. Once the user finishes defining the 
Originator and Target configurations in the SNCT, it is sent to the Originator. At this point the 
originator SCID can be confirmed by the user. This process ensures that the configuration data 
in the SNCT and originator match with a high degree of integrity. 


Then the user must place the Originator into execute mode to get the Target devices 
downloaded. If the connection is successful, the Target configuration/SCID was accepted by 
the target and confirmed by the originator. This action also established the Originator as the 
Target’s owner and prevents the Target from being downloaded by any other device except the 
SNCT. 
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Figure 7-1.6 SNCT Downloads to Originators that perform Type 1 Configuration 
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7-1.4.2.1 SNCT Downloads to Originators that perform Type 1 Configuration 

1. Clear Configuration Lock Attribute on originator 

a. Device: Configuration Lock Attribute cleared. 
2. Enter configuration state with password, TUNID, OUNID 

a. Device: No safety I/O connections can be active. 

b. Device: Device saves “Configuring” mode to NV storage 

i. Until “Validate” & “Apply”, power cycles go back to “Configuring mode 

3. Transfer of configuration data 

a. Tool: Calculate “proposed SCCRC” for data (SCCRC part of SCID) 

b. Tool: Any explicit messages are allowed to set configuration in device, but device 
shall only accept safety-related explicit messages over the connection that put it 
into the configuration mode. 

4. Validate configuration data 


a. Tool: Send Validate _Request with SCID (which contains proposed SCCRC) 
b. Device: Analyze configuration data 

ce. Device: Calculates SCCRC value and compares to “proposed SCCRC” 

d. Device: send SCID in Validate_Reply 

e. Tool: Compares returned SCCRC to “proposed SCCRC” 


5. Apply Configuration 
a. Device: Save configuration to NV storage with SCID 
b. Device: Mark configuration as valid. 
c. Device: Set mode to Idle 
d. Tool: Capture and store the SCID with the configuration file. 
6. Set Mode to Run 
a. Originator: Sends Type 2 SafetyOpens (refer to Chapter 2, Section 2-6.2) 
b. Target returns one of the following errors (assumes no others are found, refer to 
SRS11, SRS12, & SRS180 in Chapter 2): 
¢ Unconfigured: 0x01, 0x0110 — Device Not Configured 
e Prior configuration: 0x01, 0x80C - SCID Mismatch error 
c. Originator: Sends Type 1 SafetyOpen 
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7-1.5 


Targets: Verify and Apply the configuration data 
Targets: Return target SCID# to originators 
Originator: Compare sent and received SCID#’s 
Originator: Return On-Line status to SNCT 


gmee 


Verification Process 


The verification process uses the data that was transferred during any of the download 
processes to allow the user to correctly verify that the downloaded data is correct, the system 
operation is correct and the system is ready for SIL 3 operation. There are three main parts to 
the configuration process: 


e Configuration Data Verification 
e Functional testing 
¢ Configuration Locking 


Key requirements for the safety manual: 


e SRS42 The device Safety Manual shall contain an advisory that user testing is the means by 
which all downloads are validated_. 

e¢ SRS43 The device Safety Manual shall contain an advisory that the signature should only 
be considered “verified” (and configuration locked) after user testing 


SRS44 The device User manual shall contain an advisory that configuring an originator with 
connection data and/or target configuration data must be downloaded to the target so it can be 
tested and verified. Only then can SCIDs from the target be confirmed. 


As shown in Figure 7-1.7, when originators are tool-configured and targets are originator 
configured, only the originator is “locked” after verification and testing. The target in this case 
uses ownership assignments for protection. Also shown in Figure 7-1.7 is that Targets can also 
be tool-configured as well. In this case, these targets are also “locked” after verification and 
testing. 
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7-1.5.1 


7-1.5.1.1 


Figure 7-1.7 Protection from Locking & Ownership 
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User Configuration Verification and Alternatives 


The user needs to visually verify that the downloaded configuration is correct and is the 
intended configuration for the device (refer to Section 7-1.1.3). This section presents four 
alternatives that will fulfill the requirements for user verification of the device configuration 
data. In all cases the user needs to verify the functionality of the devices being configured 
through some kind of functional testing (refer to Section 7-1.1.3). 


Alternative 1 — Immediate Read Back and Diverse Comparison 


The device configuration data is read back by the work station and presented to the user 
utilizing a diverse execution path in the workstation. 


Figure 7-1.8 Example of read back and comparison of original and printout 
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7-1.5.1.2 


1. One or a combination of the following options can be used to fulfill the user verification 
requirement: 

2. User comparison of the original software display, and results of the read back that have 
been displayed by a diverse means. 


Reading back the entire configuration, comparing it to what the software has and providing a 
printout of the device configuration for the user to compare with what was previously entered. 
The user must examine and compare the printout to the original data to satisfy the integrity 
requirements. Any automated comparison by the software tools is a diagnostic and shall not be 
relied upon in and of itself to ensure integrity. 


The read back and display using a diverse means reduces the possibility of a systemic error in 
the workstation causing the same data corruption on data entry and user checking, which could 
cause an undetected error. If, for instance, a corruption occurred prior to the generation of the 
CRC the data would be interpreted as correct by the device and the same data and CRC would 
be sent back to the workstation. Automated checks of the original and read back data would 
not indicate an error, because the data matches the CRC. If the data was displayed using the 
same mechanism as the original display mechanism the error could still be masked and would 
be undetected. The diverse display paths should reduce this common cause of error. 


Alternative 2 —- Local Diverse Display 


It is possible to achieve the same level of integrity at defined in 7-1.5.1.1since it can be shown 
that the configuration data on the workstation storage is identical to the configuration data in 
the device. The verification of configuration data is accomplished by writing the configuration 
data and CRC to the local drive in the workstation. The configuration data and CRC from the 
local drive are then sent to the device. The device then verifies the correct transfer by 
comparing the data and CRC. If the transfer to the device is correct, the device sends its 
calculated CRC back to the workstation to confirm that the data was sent correctly. At that 
point the workstation compares the device CRC to the stored CRC. At this time it can be 
assumed that the data in the workstation was correctly sent to the device. It is important to note 
that the CRC is only calculated once by the workstation and stored on the local drive. It is not 
recalculated for the purpose of transfers. This also ensures the integrity of the data on the local 
drive. At this point it can be assumed that the data in the workstation was correctly sent to the 
device. 


For verification, the user shall view the “sent” configuration data using a diverse means to 
confirm that the correct configuration was sent to the device (refer to Section 7-1.1.3). Since 
the data on the workstation storage includes a CRC, a diverse means of display will allow the 
user to uncover any errors caused by the workstation when the data was entered into storage. 
This effectively duplicates the functionality of the full read back method without the overhead 
of doing a full data read back from the device to the workstation. 
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7-1.5.1.3 


7-1.5.1.4 


7-1.5.2 


Figure 7-1.9 Diverse display without full data read back 
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Alternative 3 —- Delayed Local Diverse Display 


This alternative presents a method to use a combination of the TUV preferred method and the 
Alternative 1 method described above. The goal of this method is to reduce the user interaction 
with the system. 


Initially all of the devices in the system are unverified and are downloaded with the CRC 
checking as described in Alternative 1, the user verification of the uploaded data is not done at 
this time. Once the entire system is functionally tested by the user, the entire system will be 
verified by the software tool on the workstation. The verification step shall read back all of the 
configuration data from all of the devices, compare the read back data to the local drive copy, 
and present it to the user in a diverse manner for user examination. This read back of data shall 
be performed in the manner described in section 5.4 but shall be performed for all devices in 
the system at the same time. 


This method has the advantage of allowing the user to complete the onerous visual comparison 
once, with the final tested system. 


Alternative 4 — Delayed Read back 


This alternative presents a method similar to the TUV preferred method, but with the read back 
of the configuration data from the devices delayed until the testing of the device is preformed. 
Functionally this method is identical to the TUV preferred method, but it allows the user to 
delay the visual verification until system testing is complete. 


Verification Process 


Figure 7-1.10 shows the complete process for verifying the configuration of safety devices. It 
is assumed that the data has be downloaded using the process described in section 7-1.4, 
ensuring that the SNCT and the device have the same configuration data. One alternative shall 
be selected for the user verification of the configuration data (refer to Section 7-1.1.3). Upon 
completion of this process the devices and system are ready for SIL 3 operation. 
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Figure 7-1.10 Verification Process including all alternatives 
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7-1.6 Configuration Error Analysis 


The following table shows the errors and detection measures that are considered for the 
download and configuration process defined by the SNCT interface. 


Table 7-1.2 Errors and Detection Measures 


Detection Measures 


ion! 


Errors 


ion of 


configuration 


Configuration Locking] 
lor Device Ownership 


configuration (Part of 


SCID) 


(Configuration session 


ISCCRC protection on 
control 

|User Functional 

[Read back of the 


(Testing 


User 
misdirected x 
configuration 


* 
* 


System 
misrouted x x x x x 
configuration 


Lost 
Configuration Xx XxX x 
Message 0 


Corrupted x x x 
configuration 


Configuration at 
inappropriate XxX 
time 


User loads. 
wrong x xX x 
configuration 


Configuration 
process is xX 
interrupted 


' User Authentication is an optional feature and only applies if the feature is used by the end user 


7-1.6.1 Errors 
7-1.6.1.1 User Misdirects Configuration 


The user is required to functionally test devices that are configured so user misdirection can be 
discovered during testing (refer to Section 7-1.1.3). 


If the user configures a node unintentionally and it is not noticed, the originator connecting to 
the node will not have the matching signature and will either reconfigure the device with the 
correct signature or reject the connection. Either of these two actions will result in the system 
going to a safety state. 


If the end user enables authentication features, users cannot configure nodes for which they do 
not have authorization. User authentication is an optional feature. 
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7-1.6.1.2 


7-1.6.1.3 


7-1.6.1.4 


7-1.6.1.5 


7-1.6.1.6 


7-1.6.1.7 


7-1.6.2 


System Misroutes configuration 


There are two different cases for a system to misroute a configuration: configuration preformed 
during connection establishment by a Type 1 safety open, and configuration from a workstation 
or Originator-to-Target configuration process. Both of these cases are explained in the 
following paragraphs. 


e Ifa routing error occurs during the establishment of a configuration session the 
configuration mode message will be rejected by the device because of the wrong TUNID or 
OUNID in the mode message. 

e Ifaconfiguration message is misrouted within a configuration session, it will be rejected by 
the receiving device if the device is not in the correct mode or is received on a connection 
other than the connection used to establish the configuration mode. If the device is in the 
correct mode the configuration message would have to be addressed to the correct class, 
instance, attribute to be accepted and would be discovered during the SCID validation steps. 
The device that was supposed to correctly receive the configuration message will also fail 
the SCID validation. The user will also discover this during the check of the configuration 
read back from the device. 


Lost Configuration Message 


The detections for a lost message are the same as those for a misrouted message. 


The Configuration Is Corrupted 
If for any reason the configuration is corrupted, it will be detected by the SCID checks, the user 
functional testing, and the user configuration examination. 

Configuration at an Inappropriate Time 
Configuration of operating devices is prevented by the user authentication and setting of the 
configuration mode. If a user attempts to configure a device that the user is not authorized for 
the mode request will be rejected. If the user sends configuration messages to a device without 
the configuration mode set the device will reject the changes. 

User Loads the Wrong Configuration 
Each configuration is uniquely identified by the SCID. Users are required to implement 
procedures to verify that the configuration being loaded is the correct one for the application. 

Configuration Process Is Interrupted 
If the configuration process is interrupted for any reason the device will remain in the 


configuration mode until a valid configuration is loaded and the mode is changed. 


When the configuration process is interrupted the process will need to be restarted on a new 
connection with a new configuration request. 
Detection Measures 


The following sections will explain each of the detection measures that are used by the SNCT 
interface for the detection of the errors during the download process. 
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7-1.6.2.1 


7-1.6.2.2 


7-1.6.2.3 


7-1.6.2.4 


7-1.6.2.5 


7-1.6.2.6 


7-1.6.2.7 


User Authentication 


All safety devices have optional password protection. The Configuration Lock, Configuration 
Request, Mode Change, and Reset commands all require the use of a password to change the 
state. 

Identification of Configuration File 


All safety configuration files are uniquely identified by the SCID See Section 7-1.3.1 


Identification of target to be configured 


The configuration mode message and the verify message both use the TUNID for identification 
of the target. See Section 7-1.3.5 


CRC protection on configuration 


Part of the SCID is the SCCRC. The SCCRC is 32 bit CRC that is calculated over the safety 
configuration data. See Section 7-1.3.2 


Configuration Ownership 


When an out-of-box target device is configured by an originator, the device captures the 
OUNID and subsequently prevents any other originator from configuring the device. Thus the 
ownership assignment (OUNID) provides a means of locking this device to a single 
configuration source. See Section 7-1.3.5 


Configuration Session Control 


Prior to configuring a device it must be placed into a configuration mode. The configuration 
mode is persistent in the device and remains in place until the device is set to another mode by 
acommand. SRS33 The configuration mode in safety devices implementing the SNCT 
interface shall persist through power cycles. 


SRS34 Upon entering the configuration mode, devices implementing the SNCT interface shall: 


e Store the configuration mode in NVS 
e Mark the existing configuration invalid 


¢ Lock out all configuration messages for connections other that the one that set the 
configuration mode. 


SRS35 To enter the configuration mode, devices implementing the SNCT interface shall: 


¢ confirm User Password in the configuration mode command 
e confirm TUNID in the configuration mode command 


User Functional Testing 


The user is required to functionally test new and replacement devices prior to utilizing the 
system in a SIL3 environment. 
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7-1.6.2.8 


7-1.7 


7-1.8 


Configuration Protection 


After configuration, testing, and user verification has been completed by one of the procedures 
defined in Section 7-1.5.1, all tool-configured devices are locked. These are Targets, 
Originators, or both. This locked state can be read to provide an indication that the 
configuration has been verified and also guards against inadvertent configuration changes by 
requiring the user to first unlock the device. 


As a result of user testing, originator-configured target devices have ownership assignments 
which binds these devices to their owners; effectively locking these devices from being 
inadvertently configured by some other source. As shown in Figure 7-1.7, the combination of 
locked tool-configured originators and owned targets provides a secure environment to protect 
the verified system from unauthorized changes. 


Diagnostic Software Protections (Not Safety Related) 


[he software may also implement data protection measures of the device configuration data as 
a data integrity measure and for the early error detection mechanism. It is important to note 
that these measures are not safety related and therefore do not need to achieve SIL3 or be 
certified. These areas are defined here: 


Storage of Configuration Data to Hard Disk, CD, etc shall include the SCID and be checked 
during a file load operation. 


[he transfer of Configuration Data across software interfaces shall include the SCID and be 
checked by the receiving software component (refer to Section 7-1.1.3). 


Device Memory Architecture Considerations 


It is important to understand the memory architecture that target devices could use to know 
how it could behave during configuration. All these architectures are supported by this 
specification but will change the behavior for the user. 


There are 3 distinct data areas defined with respect to configuration: 


NV stored copy — this is a valid configuration stored in Non-volatile memory and is what is 
used to set up a safety device on power-up. 


Working RAM copy — This is a valid configuration that is an exact copy of the configuration 
in NV memory, but is what is used during run-time operation. 


Editable RAM Copy - This is a data space that can be modified by software in the 
configuration mode, but has yet to be applied. 


Product developers may choose to implement one or more of these data areas to increase user 
flexibility. 


NV Copy Only — This design approach keeps configuration only in NV memory. When the 
configuration mode is entered, the entire configuration is invalidated and there is no possibility 
to restore the configuration. The software must successfully download a complete and valid 
configuration to the device. Once it is validated and applied the NV copy is marked as good. 
The restore command is not supported in this type of device. 
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NV and Working Copy — This design approach keeps configuration in NV memory and a 
working copy in RAM. When the device enters the configuration state, the working copy is 
modified, but until the configuration is validated and applied, the old valid configuration is still 
available to be restored. A power cycle before the Apply would revert to the last configuration 
in NV memory. The restore command is supported and would re-copy the NV version into 
working RAM. 


NV and Working Copy with Edit buffers — This design approach keeps a valid working 
configuration at all times until a “validate and apply” is done. If the configuring device quits 
without applying the changes, the restore command would allow the device to simply exit the 
configure state and run with what is in memory. The restore command is supported, but no 
copy from NV RAM is needed, the working copy can be used. 
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7-2 
7-2.1 
7-2.1.1 


7-2.1.2 


7-2.1.3 


7-2.2 
7-2.2.1 
7-2.2.1.1 


Electronic Data Sheets 


General Rules for EDS based Safety devices 
Safety Configuration Assembly Definition 


Like most CIP devices, safety devices can be configured from an EDS file definition. 


FRS349 Safety devices that are configured via EDS file shall define a Configuration 
Assembly so that the software knows how to calculate the SCID. 


A standard EDS assembly section shall be used to define the various parameters contained in 
the Safety Configuration Assembly so the software can provide appropriately useful user 
prompts. A field and keyword has been defined in the [Parameter Class] section to identify the 
instance Id of the assembly. A connection manager entry shall also be used to reference this 
assembly if it is to be configurable with a Typel SafetyOpen. This reference will publicize to 
the SNCT which originator connections are appropriate to configure the device. 


Configuration CRC 


[he SNCT and EDS based safety device must agree on a method for calculating the SCCRC. 
EDS based safety devices shall use CRC-S4 with the seed value defined in Appendix E. The 
ata input to the CRC algorithm is defined by the Configuration Assembly. Any padding in the 
configuration assembly will be assumed to be zero for purposes of calculating the SCCRC. 


Password Encryption for EDS Devices 


The SNCT and any other configuration software implementing the SNCT interface shall have a 
standardized method for encrypting passwords prior to presenting them to a safety device. 
Software tools implementing the SNCT interface shall use CRC-S4 with the seed value defined 
in Appendix E. 


When an encrypted password is smaller than the fixed-size password parameter, the method 
described under the Set_Password service in the Safety Supervisor object definition shall be 
used. 


General EDS Extensions for Safety 
Extension to [File] Section for Safety 


EDS File CRC 


EDS Files for safety device shall be protected by a CRC. CRC-S4 with the seed value defined 
in Appendix E shall be used. 


The EDS File CRC value shall be entered in the [file] section with the entry keyword 
“EDSFileCRC=”. The EDSFileCRC entry keyword shall be contained on a single line. 


The SNCT shall confirm the EDS file CRC prior to using the file contents as described below: 


Open file as a binary file. Load the entire file into memory. 


Ls 
2. Remove the entire line including the carriage return that has the EDSFileCRC= entry. 
3. Calculate the CRC over the remaining contents of the file. 
4. Compare the calculated CRC to the EDSFileCRC= entry’s value. 
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7-2.2.2 


7-2.2.2.1 


SRS207 An “EDSFileCRC=” keyword and value shall be included in all safety device EDS 
files. If the [Device Classification] entry describes the device as having any Safety capabilities 
and the EDSFileCRC= entry keyword does not exist, then the SNCT shall not use the file. 


Extensions to [Device Classification] Section for Safety 


SRS206 The EDS file for safety devices shall include a [Device Classification] section which 
shall contain a Classx keyword that indicates the Safety classification. 


The Classx keyword, with the Classification field equal to Safety, is defined in Table 7-2.1. 


Table 7-2.1 Safety Classx Entry Format 


Field Name Field Number Data Type Required/Optional 
Classification 1 Field Keyword Required 
Reserved 2,3 empty 
Port Instance 4,5,...0 UINT Conditional ' 
1 Required if the device supports more than 1 CIP port 


e Classification shall be the value Safety. 
e The Port Instance fields are the Port Object instances that support safety. 


Example 


EDS snippet showing how a 2 port device, TCP (EtherNet/IP) and DeviceNet, indicates that 
Safety is only supported by the DeviceNet port. 


[Port] 
Portl = TCP, $ Port type 
"ENet", $ Port name 
"20 F5 24 01", $ Path to Port object, The TCP/IP object 
a7 $ Internal Port Number 
Port2 = DeviceNet, § Port type 
"DNet", $ Port name 
"20 03 24 01", $ Path to Port object, The DNet object 
4; § Internal Port Number 
[Device Classification] 
Classl = DeviceNet; S$ DeviceNet class device 
Class2 = EtherNetIP; $ EtherNet/IP class device 
Class3 = Safety, $ Safety class device 
’ 
2; $ Safety supported on Port Instance 2, 


§$ the DeviceNet port 
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7-2.2.3 


7-2.2.3.1 


7-2.2.4 


Extension to [ParamClass] Section for Safety 


Parameter Class SafetyCfgAssembly Keyword 
Table 7-2.2 Parameter Class Keywords 


Entry Name Entry Field Data Type Required/Optional 
Keyword Number 
Max Instances MaxInst 1 UINT Required 
Parameter Class. Descriptor 1 WORD Required 
Descriptor 
Safety Assembly SafetyCfgAssembly 1 UINT Conditional! 
Instance 


: Required for Safety devices that are configured via EDS file 


SafetyCfgAssembly — Identifies the configuration assembly object instance number for safety- 
related parameters in this device. 


SRS208 A “SafetyCfgAssembly=” keyword entry shall be included for Safety devices that are 
configured via EDS file. This value shall also match an AssemN entry keyword specified in 
the [Assembly] section. 


Example: 
$ This device has only one configuration assembly and all the parameters are safety-related 


[Parameter Class] 
MaxInst = 3; 
Descriptor = 0x0E; 
SafetyCfgAssembly= 4; 


Extension to [Connection Manager] Section for Safety 


There are four new keywords defined for safety that are described in this section. The new 
keywords are summarized in Table 7-2.3. 


Table 7-2.3 New Connection Manager Section Keywords for Safety 


Entry Name Entry Keyword Field Data Required/Optional 
Number Type 

Maximum Safety MaxSafetyConnections 1 USINT | Optional 
Connections 
Maximum Safety MaxSafetyInputCnxns 1 USINT | Optional 
Input Connections 
Maximum Safety MaxSafetyOutputCnxns 1 USINT | Optional 
Output Connections 
Default Safety DefaultSafetyConnections 
Connections 

Connection Instance 1 1 UINT Required 

Connection Instance n n UINT Conditional 
Safety Format SafetyFormat 1 USINT | Optional 
Supported 

— 7-28 — 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 7: Safety Device Configuration 


7-2.2.4.1 Max Safety Connections 


Safety devices will typically support a large number of possible assemblies that mix and match 
different combinations of I/O data and/or status. At the same time, these devices have a limit 
on how many safety I/O connections can be established at any one time. These keywords in 
the [Connection Manager] section define these limits. If no entry exists in the EDS file, no 
limits exist. 


7-2.2.4.1.1 Examplel 
A device can support 4 safety connections, and they can be of any type 
[Connection Manager] 
MaxSafetyConnections = 4; 


MaxSafetyInputCnxns = 4; 
MaxSafetyOutputCnxns = 4; 


7-2.2.4.1.2 Example2 


A device can support 4 safety connections. 

Up to 4 input connections, but only | output connection 

{Connection Manager] 
MaxSafetyConnections = 4; 
MaxSafetyInputCnxns = 4; 
MaxSafetyOutputCnxns = 1; 


7-2.2.4.2 Default Safety Connections 


There will often be a set of connections that are most commonly used. Product developers can 
optionally define a default set of connections that allow the user to quickly and easily add these 
connections to an originator configuration. The DefaultSafetyConnections entry keyword 
specifies which connection manager entries are these “default” connections. 


7-2.2.4.2.1 Example 


A device has one default input and output connection. The device’s EDS file has 8 possible 
connections defined, but the defaults are defined in connection! and connection7. To inform 
the software of this, the following entry is made in the [Connection Manager] section. 


[Connection Manager] 
DefaultSafetyConnections= 1,7; 


7-2.2.4.2.2 Safety Format Support 


A device which supports the extended format must declare that support by entering this 
keyword in the Connection Manager section of the device’s EDS file. By making this 
declaration, connection configuration software algorithms can be enabled to configure a new 
format type attribute in the Connection Configuration object. When this keyword is not present 
in an EDS file, it will be assumed only the base format is supported (equivalent to 
SafetyFormat = 1). For more information, refer to Section 2-10 and Section 5-6.2.6. The 
possible options are: 
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sea eepae Value Semantic 
Base Only 1 Supports Base Format only 
Extended Only 2 Supports Extended Format only 
Base and Extended 3 Supports both the Base and Extended Formats 


For example, to make the declaration that both formats are supported, the following entry is 
made in the [Connection Manager] section. 


[Connection Manager 


SafetyFormat = 3; $ supports both base and extended format 


7-2.2.4.3 Changes and Additions to Connection Fields 


A Connection manager entry shall be defined for each CIP addressable safety component to 
which a connection can be established. The safety connections are defined using the existing 
Connection Manager section defined in Volume 1, Chapter 7 with the following extensions. 
The SNCT shall use each entry to present the user with a set of connection options that can be 
connected to from an originator. 


The following is the list of fields currently defined for the Connection Manager section. 


Table 7-2.4 Connection Manager Field Usage for Safety 


Field Name Field Data Type Usage for Safety 
Number 
Trigger and 1 DWORD Class: shall be only 0 
transport Trigger: shall be application 


Application type: 
producers shall be Input Only 
consumers shall be Exclusive Owner 


examples: 
producers (clients): 0x02040001 
consumers (server): 0x84040001 


Connection 2 DWORD O=>T size: shall only be fixed 
parameters T=>0 size: shall only be fixed 


Bytes per slot: always ignored 

Real Time Transfer format: 5 = Safety 
Priority: always High 

Connection Type: 

Inputs: 


‘=>O Multi-cast or Point-to-point 
O=>T Point-to-point 
T & T=>0 Point-to-Point 


examples: 
Multi-cast Input (producer): 0x22645505 
Single-Cast Output (consumer): 0x22445505 


O=>T RPI 3 Param Either leave blank or provide Param reference to define device 
capability 
O=>T size 4 UINT or If blank, will either assign the size from the associated ASSEM 
Param reference or the software will use the Time Coordination size. (See 


Volume 5, chapter 2-1.7.1.5) 


O=>T format | 5 Assem For Safety output connections, this field shall indicate the Safety 
output assembly to which the connection is associated. For safety 
input connections, this field shall be empty 
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7-2.2.4.3.1 


Field Name Field Data Type Usage for Safety 
Number 

T=>0 RPI 6 Param Either leave blank or provide Param reference to define device 
capability 

T=>0 size 7 UINT or Tf blank, will either assign the size from the associated ASSEM 

Param reference or the software will use the Time Coordination size. (See 
Volume 5, chapter 2-1.7.1.5) 

T=>0 format | 8 Assem For Safety input connections, this field shall indicate the Safety input 
assembly to which the connection is associated. For safety output 
connections, this field shall be empty. 

proxy config 9 UINT or Can optionally be used 

size Param 

proxy config 10 Param or Can optionally be used 

format Assem 

target config 11 UINT or Size of configuration assembly when device supports configuration 

size Param via Type 1 SafetyOpen. 

target config 12 Param or This field can indicate which assembly will hold the Type 1 

format Assem SafetyOpen configuration data. 

Connection 13 Eds_Char Unique name to allow a user to identify the application assembly to 

name string Array which this instance is associated 

Help string 14 Eds_Char User help message related to using the connection. 

Array 
Data Path 15 Eds_Char Complete path comprising of Config, Consumed, and Produced path. 
Array Null paths are inserted where no path exists (see possible formats 
below). 

ASYNC! 16 USINT This is a CIP Safety exclusive field. 

Only applies to producing connections. Field should be empty for 
consuming connections. Used to calculate Network Reaction Time 

Max 17 USINT This is a CIP Safety exclusive field. 

Consumer When safety devices wish to define multi-cast connections and need 

Number 


to restrict the max number of consumers to a value less than the 
default maximum of 15, this field can define the product limit. If this 
field is empty, the SNCT shall always use the default value of 15 for 
the maximum number of multi-cast connections. This field can be 
left empty for single-cast connections. See section 2-4.5.2.5 — 
Max_Consumer_Number for the definition of legal values for this 


field. 


' ‘This field is specified only for safety related specifications and shall either be empty or omitted for non-safety 


related connection manager instances. 


Trigger and Transport Field 


Safety devices will define whether a connection is a producing (client) or consuming (server) 
connections by filling out this field. The other parts of the field will have fixed definitions as 


follows: 


Class: always 0 


Trigger: always application 
Transport type: all 0 


examples: 
producers (clients): 0x0004 0001 
consumers (server): 0x8004 0001 
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7-2.2.4.3.2 


7-2.2.4.3.3 


7-2.2.4.3.4 


7-2.2.4.4 


Connection Parameter Field 


Safety Devices define what types of connections are possible for a connection by using this 
field. Typically producing (inputs) connections can support T=>O multi-cast or point-to-point, 
and outputs will always only allow O=>T as single-cast. In both cases, the connection type in 
the opposite direction will always be point-to-point only. All the other fields will have fixed 
values. The following table provides the only valid values for Safety devices. 


Table 7-2.5 Connection Parameter Field Settings for Safety 


Connection Type Connection Parameter Setting 
Producing (client) input connection 0x22645505 or 0x22445505 (no multi-cast) 
Consuming (server) output connection 0x22445505 
Data Path Field 


Volume 1, section 3-5.5.1.10 defines a method to construct an application path in a Forward 
Open for 3 references: one for configuration, one for consumed data, and one for produced 
data. With the introduction of NULL paths for safety, there are some additional requirements 
for safety. Refer to Chapter 3, section 3-3.7 for more information. 


Safety ASYNC Field 


This parameter is necessary to properly calculate the Network Reaction Time for a safety 
connection. This parameter is generally different for input connection and output connections 
but is design dependent. This field is required in the Connection Manager section for producing 
(client) connections. Devices which produce on input connections must define a Safety 
ASYNC value for those connections, and devices which produce on output connections (i.e. 
logic devices or scanners) must define a Safety ASYNC value for these connections. Any value 
provided on consuming (server) connections will be ignored by the software. 


SRS49 If a Safety ASYNC parameter is not defined in a producing connection, the software 
shall use a worst-case default value of 1. 


Safety ASYNC = 0 = synchronous 
Safety ASYNC = 1 = asynchronous 


[Connection Manager] for Safety Example 
$ Sample Electronic Data Sheet illustrating the Parameter Groups 
Section 
[File] 


[Device] 
[Device Classification] 


[ParamClass] 
MaxInst = 2; 
Descriptor = 0x0E; 


~7-32- 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 7: Safety Device Configuration 


SafetyCfgAssembly= 1; 


[Params] 
Paraml = 
) 


6, "20 OF 24 01 30 01", 


0x0000, 

2, 

2, 

"Idle state", 


ww 
, 


"User Manual p48", 


0, 2, 1, 

0, 0, 0, 0, 
0, 0, 0, 0, 
0; 


Param2 = 0, 6, 
0x0000, 2, 2, 
"Fault state", 


ow 
, 


"20 OF 24 02 30 01", 


$ first field shall equal 0 
$ path size, path 
$ descriptor 


$ data type: 16-bit WORD 
$ data size in bytes 
$ name 
$ units 
$ help string 
$ min, max, default data values 
$ mult, dev, base, offset scaling not used 
$ mult, dev, base, offset link not used 


$ decimal places not used 


$ path size, path 


"User Manual p49", 
0, 2, 2, 0, 0, 0, 0, 


0, 0, 0, 0, 0; 


[Assembly] 

Revision = 2; 

Asseml = "Safety Configuration", "20 04 24 01 30 03", 
1, $ size = 1 byte 
0, $descriptor = assembly “not editable” 
tr $reserved 
4, Paraml, $4-bits 
3, Param2, $3-bits 
1,7 

Assem2 = "Safety Inputs", 


"20 04 24 02 30 03", 


Scan be read via explicit message 


ds § size = 1 byte 
0, $descriptor = assembly “not editable” 
i Sreserved 


, 
1, "20 08 24 01 30 03", 
1, "20 08 24 02 30 03", 
6 


$Discrete Input Point 1 
$Discrete Input Point 2 


; $6 pad bits 


Assem3 = 


"Safety Outputs", 
"20 04 24 03 30 03", 
1, $ size = 
0, Sdescriptor = 


Scan be read via explicit message 
1 byte 
assembly “not editable” 


" Sreserved 


, 
1, "20 09 24 01 30 03", 
1, "20 09 24 02 30 03", 
6 $6 pad bits 


OF 


{Connection Manager] 


MaxSafetyConnections = 
MaxSafetyInputCnxns = 
MaxSafetyOutputCnxns = 
DefaultSafetyConnections = 


SafetyFormat = 3; 


Connectionl = 


$Discrete Output Point 1 
$Discrete Output Point 2 


2; 


1; 


1; 
1,2; 


$Input Connection Configuration 
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0x00040001, $ trigger & transport 
$ class 0, application trigger, client 
0x22645505, $fixed sizes, safety formats 


$ O=>T point-to-point, 
$ T=>0 multicast or point-to-point 
$ priorities high 
na § Time Coordination parameters left blank 


mr $ RPI set at originator, size obtained from ASSEM 


[Assem2], $ produced data from assembly 2 
ier $ config part 1 (not used) 


, (Asseml1], $ Type 1 config accepted on this connection, 


$ size comes from ASSEM 
"Safety Input 1", $ connection name 
mn $ Help string 
20 04 24 02 20 04 24 FF 20 04 24 03, 

$ Long format 


Produced @ instance 03 
asynchronous interface 
15 max consumers 


1 
15; 


Connection2 = $Output Connection Configuration 
0x80040001, $ trigger & transport 
$ class 0, application trigger, server 
0x22445505, $fixed sizes, safety formats 
$ O=>T point-to-point, 
$ T=>0 point-to-point 
$ priorities high 


Config @ instance 2, Null @ instance OxFF, 


fa $ RPI set at originator, size obtained from ASSEM 


[Assem3], consumed data to assembly 3 
Time Coordination parameters left blank 


config part 1 (not used) 


ree 
a 
, [Assem1], 
size comes from ASSEM 
connection name 
Help string 
20 04 24 02 2C 03 2C FF, 
$ Compressed format 
Config @ instance 2, Consumed CP=03, 
Null CP=0xFF, 
ASYNC and Max consumers 


"Safety Output 1", 


uw 
, 


OUMNH KNUH 


nn YD 
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8-1 Introduction 


This chapter of the CIP Safety Networks specification contains additions to the Physical Layer 
that are safety specific. At this time, no such additions exist. 


ee 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 8: Physical Layer 


This page is intentionally left blank 


~8-4— 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 9: Indicators and Middle Layers 


Volume 5: CIP Safety 


Chapter 9: Indicators and Middle Layers 


=O = 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Chapter 9: Indicators and Middle Layers 


Contents 


9-1 Indicators 
9-1.1 CIP Safety Indi 
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9-1 


9-1.1 


9-1.2 


Indicators 
Indicators assist maintenance personnel in quickly identifying a problem unit. This is 


accomplished through the consistent placement and presentation of indicators on DeviceNet 
products. 


This section refers to Indicators that are visible to maintenance personnel. Visible means that: 


e Indicators can be viewed without removing covers or parts from the equipment. 
e Indicators can be seen in normal lighting. 


Any labels and icons must be visible whether or not the Indicator is illuminated. 


CIP Safety Indicator Requirements 

CIP Safety devices are required to have module and network indicators. 

Device developers are free to have additional indicators on their products if they so desire. 
Important: SRS186 CIP Safety Device shall provide a separate Module Status LED and a 
Network Status LED. In this case, these indicators provide important additional safety-related 
information to the user that cannot be accomplished with a combined Net/Mod Status 


indicator. 


Important: If there is a conflict between turning an LED on Red versus Green, the LED 
should be turned on Red. 


LED Indications for setting the device UNID 
The following Table shows the way the LED indications are used for setting the UNID. 


Table 9-1.1 LED Indications for Setting UNID 


Safety Supervisor MOD LED NET LED 
State/Event 
Self-test Flash Red/Green Off 

Waiting for TUNID Flash Red/Green Connection dependent 

Waiting for TUNID Flash Red/Green Flash Red/Green 

Proposed UNID Revd 250ms/250ms 
Reuse DeviceNet Group 4 
pattern 
Configuring Flash Red/Green Connection dependent 
Idle Flashing Green Connection dependent 
Executing Green Connection dependent 
~9-3- 
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9-1.3 


9-1.4 


9-1.5 


Module Status LED 


This bi—color (green/red) LED provides device status. It indicates whether or not the device has 
power and is operating properly. Table 9-1.2 defines the Module Status LED states. Table 9-1.2 
shows the Module Status LED conditions for Safety Devices (which must use the Safety 
Supervisor Object). The states shown reflect the device states specified in the Identity Object. 
These states are also mapped to the states defined in Safety Supervisor Object. 


SRS 187 For safety devices which use the SNCT interface, the states of the Safety Supervisor 
shall be what determine the Module LED status. 


Table 9-1.2 Module Status LED 


For Safety Supervisor LED is: To indicate: 
state: 
No Power Off There is no power applied to the device. 
Executing Green The device is operating in a normal condition 
Idle state Flashing Green ' | The Device is in the Idle or Standby State. Reference the Identity 
Object or Safety Supervisor Object a 

Abort Flashing Red i Recoverable Fault 
Critical Fault Red The device has an unrecoverable fault, may need replacing 
Device Self Testing, Flashing Red- The Device is in Self Test or the Device needs commissioning due 
Waiting_for_TUNID or Green! to configuration or UNID missing, incomplete or incorrect *. 
Configuring” Reference the Identity Object or Safety Supervisor Object ~ 


' For information on LED flash rates, refer to section 8-2.8, DeviceNet Spec Vol. | 
* The state of Safety Devices is determined by the Safety Supervisor Object 


* An Unconfigured/unowned Safety Device should not be allowed to persist while connected to an active safety 
system. 


Indicator Warning 


SRS105 The User Safety Manual shall provide a warning that states “LEDs are NOT reliable 
indicators and cannot be guaranteed to provide accurate information. They should ONLY be 
used for general diagnostics during commissioning or troubleshooting. Do not attempt to use 
LEDs as operational indicators”. 


Network Status LED 


This bi-color (green/red) LED indicates the status of the communication link. For DeviceNet 
Safety devices, refer to chapter 6, section 6.2, Figure 6.1, Network Access State Transition 
Diagram, of the DeviceNet Specification to compare the Network Status LED to the Network 
Access State machine. 
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9-2 
9-2.1 


9-2.1.1 


9-2.1.2 


Table 9-1.3 Network Status LED states. 


For Safety Supervisor LED is: To indicate: 
state: 
Not Powered/Not On-line | Off Device is not on-line. 


The device has not completed the Dup_MAC_ID test yet. 
The device may not be powered, look at Module Status LED. 


On-line, Not Connected Flashing Device is on-line but has no connections in the established state. 


H 
Green The device has passed the Dup_MAC_ID test, is on-line, but has no 


established connections to other nodes. 
For a Group 2 Only device it means that this device is not allocated to 
a master. 


For a UCMM capable device it means that the device has no 
established connections. 

For Safety Devices, a connection may be established, but the 
Validator has not completed an initial Time Coordination exchange. 


Link OK, On-line, Green The device is on-line and has connections in the established state. 
Connected 
Connection Time-out Flashing One or more I/O Connections are in the Timed—Out state. 
Red! 

Critical Link Failure Red Failed communication device. The device has detected an error that 

has rendered it incapable of communicating on the network 
Communication Faulted Flashing A specific Communication Faulted device. The device has detected a 
and Received an Identify | Red-Green | Network Access error and is in the Communication Faulted state. The 
Comm Fault Request — device has subsequently received and accepted an Identify 
Long Protocol or Communication Faulted Request - Long Protocol message. 
Propose_TUNID service Safety devices use this indication to allow maintenance personnel to 


received 


commission the UNID in a safety device. 


' For information on LED flash rates, refer to section 8-2.8, DeviceNet Spec Vol. | 


Switches 
Switch Behavior on CIP Safety 


MACID Switches 


The following algorithm can also be applied to the handling of the Baud Rate switch if 
implemented. When hardware switches are used for setting MACID and/or Baud Rate there 
are some differences in how these values are processed in safety devices. This section will 
outline the algorithm. 


There is direct relationship between the MACID setting and the MACID portion of the Target 


UNID (TUNID) in the safety supervisor. Refer to the Safety Supervisor object for more 
information. 


MACID determination 


During device initialization, the MACID switches are read by the device firmware. 


SRS106 The MACID attribute (if supported) in the DeviceNet object shall always reflect the 
value in use. 
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The following logic is applied. 


e SRS110 When the switches are read, if the switches specify a valid MACID, (a value from 
0 to 63 for MACID), this value shall be used as the MACID. 

e SRS111 When the switches are read, if the specified MACID differs from the value stored 
in the DeviceNet object’s MACID Attribute (NVRAM values), the appropriate attribute/s 
shall be updated and saved to NVRAM. 

e When the switches are read, if the switches specify an invalid MACID, (a value greater than 
63), the device should follow one the recommended options in the DeviceNet standard. 

¢ SRS113 When the switches are read, if the switches used to specify the MACID are set to a 
valid value (a value from 0 to 63 for the MACID), the MACID attribute shall have Get Only 


access. 


e SRS114 When the switches are read, if the switches are set to the software 


configuration (63 for the MACID) . 


e SRS121 If the device is out-of-box it shall use the current 


are valid values 


FRS350 Safety devices shall monitor and detect changes in t 


programmable mode (>63 for the MACID), the MACID attribute shall have Set access. 
e¢ SRS115 If a device has no switches it shall use default va 


lues for MACID in its out-of-box 


MACID switch settings if these 


he MACID or the IP Attribute and 


Baud Rate (if applicable) switch settings. Developers are free to determine an appropriate 


sample period for this detection. 


FRS351 When a MACID switch setting change is detected, the device shall update the 
MACID_Switch_Value attribute. If the MACID switch equals the MACID in use or the 


MACID Switches are greater than 63 and software settable c 


lear the MACID changed attribute 


and make no change in the state of the device, otherwise set the MACID changed attribute and 


transition to the ABORT state. (refer to flow chart in Figure 


FRS364 When an IP switch setting change is detected it shal 
mismatch condition. If the IP switch differs from the IP Add 


the ABORT state. 


FRS354 When a Baud Rate switc! 


9-2-1) 


| determine if the change creates a 
ress attribute, it shall transition to 


setting change is detected, the device shall update the 


Baud_Rate_Switch_Changed attribute and the Baud_Rate_Switch_Value attribute, then 


transition to ABORT. 


FRS352 If a CIP safety device su 


pports the Set_attribute service to the MACID or IP address 


attribute, and the MACID or IP address switches are set to enable the set service, Safety 
devices shall only accept the Set_Attribute while in the “Waiting for TUNID” state. 


Otherwise, it shall reply with a “Device State Conflict”. 


FRS353 If a CIP safety device su 
Safety devices shall only accept tl 


pports the Set_attribute service to the Baud Rate attribute, 
he Set_Attribute while in the “Waiting for TUNID” state. 
Otherwise, it shall reply with a “Device State Conflict”. 
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Figure 9-2-1 Safety Device MACID Processing Logic 
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9-2.1.3 


Use 


Cases 


CASE 1: Initial Power on, MACID switches indicate valid position, UNID is at default 


AA sali cod Sali am 


The Target UNID value stored in NVS contains an invalid Number (default (REQ)) 

User sets MACID switches. 

User powers up device 

Device reads valid switch settings. 

Device uses the settings and updates the MACID in the DeviceNet object (NVRAM). The 


MACID attribute is made “gettable” only. 

6. Device Execute DupMac check with current MACID 

7. Device reads Target UNID attribute (Safety Supervisor) and updates SNN attribute in 
DeviceNet object with SNN portion of UNID. 


oe 


Device detects an default Target UNID 


9. Device transits to “waiting for TUNID” (refer to Figure 9-2-1) 


w 


ol 


red/green pattern, and replies with success. 


8 
9.7 


CAS 


ONO Be. OF 


0. Since the device has no Target UNID, the first connection request the device will respond 
with a “UNID Not Set” error. 

1. The originator responds with a Propose_TUNID service. 

2. Device compares the MACID portion of the Target UNID to the MACID value in the 
DeviceNet object 


if the proposed Target UNID matches the Macld values, it saves the proposed Target 


UNID into the Proposed_TUNID attribute, begins flashing the NET LED with the 


. The originator (based on acknowledge controls) sends an Apply_TUNID that matches the 
Proposed_TUNID attribute. 

5. The device stops flashing the NET LED, saves the UNID to NV memory, saves the SNN 
portion to the SNN attribute in the DeviceNet object and resets the Proposed_TUNID to 
default. This update shall be done with safety integrity. 

6. Device transits to “Configuring” mode (device is not configured) 

7. Since the device is out-of-box, on the next connection request the device will respond with 
a Signature mismatch. 

. Device is configured (Tool or Type 1 SafetyOpen) 


. The completion of the Type 1 SafetyOpen or the Apply service that completes the 
configuration. 
20. Device is ready for normal operation 


E 2: Initial Power on, MACID switch in position >63, UNID is at Default 


The Target UNID value stored in NVS contains an invalid Number (default) 
The MACID attribute in the DeviceNet object represent default value (REQ) 


MACID switches do not represent valid address (>63) 

User powers up device 

Device reads switches and recognizes invalid address 

Device reads Target UNID attribute (Safety Supervisor) and updates Safety Network 


Number attribute in DeviceNet object with SNN portion of Target UNID. 

7. Device detects the default Target UNID, so the device uses the default MACID. This 
operation shall be done with safety integrity. 

8. Device uses default value (63) and executes NASM (DUPMAC check) 

9. Device transits to “waiting for TUNID” (refer to Figure 9-2-1) 

10. User sets MACID with Set_Attribute_Single() service. Address is stored to DeviceNet 
object attributes 

11. Device executes NASM (DUPMAC check) with new value 
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. Device UNID- MACID comparison check. Since the UNID is at default, the device goes 


to “Waiting for TUNID” (refer to Figure 9-2-1) 


. Since the device has no Target UNID, the first connection request the device will respond 


with a “UNID Not Set” error. 


. The originator responds with a Propose_TUNID service. 
. Device compares the MACID portion of the Target UNID to the MACID value in the 


DeviceNet object 


. If the proposed UNID matches the MACID, it saves the proposed UNID into the 


Proposed_TUNID attribute, begins flashing the NET LED with the red/green pattern, and 
replies with success. 


. The originator (based on acknowledge controls) sends an Apply_TUNID that matches the 


Proposed_TUNID attribute. 


. The device stops flashing the NET LED, saves the Target UNID to NV memory, save the 


SNN portion in the Safety Network Number attribute of the DeviceNet object, and resets 
the Proposed_TUNID to default. This update shall be done with safety integrity. 


. Device transits to configure mode (out-of-box condition) 
. Upon the next connection request the device will respond with an error (Signature 


mismatch) 


. Device is configured (Tool or Type 1 SafetyOpen) 
. The completion of the Type 1 SafetyOpen or the Apply service that completes the 


configuration will store the device configuration. This update shall be done with safety 
integrity. 


CASE 3: Modification of MACID Switch. 


Unit is operating, MACID switch in range of 0-63, UNID has a non-default setting and 
MACID matches the UNID value. 


1. 
2. 
Ds 


4. 
5. 


User sets MACID to new position 

Device detects that the MACID switch has changed and the switches are in range 0-63 
DeviceNet object MACID_Switch_Changed and MACID_Switch_Value attributes are 
updated. 

Device transitions to ABORT state, MOD LED changed to flashing red. 

device continues to use the "old" MACID 


CASE 4: Set_attribute service changes the MACID while operating normally. 


Unit is operating, MACID switch in position >63, UNID has a non-default setting and 
MACID matches the UNID value. 


Pans 


Device is in a state other than “Waiting for TUNID” 

MACID switches set to address >63 

User attempts to set MACID with Set_Attribute_Single() service. 

Device sends error reply with error code “Device State Conflict” (refer to Figure 9-2-1) 
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CASE 5: Set_attribute service changes the MACID while device is “Waiting for TUNID”. 
MACID switch in position >63, MACID in NVRAM has valid value, UNID value is at 
default. 


Device powered up using the MACID stored in NVRAM 

UNID was at default, so device enters “Waiting for TUNID” 

MACID switches set to address >63 

User sets MACID with Set_Attribute_Single() service. Address is stored to DeviceNet 

object attributes 

5. Device executes NASM (DUPMAC check) with new value 

6. Device UNID- MACID comparison check. Since the UNID is at default, the device 
remains in “Waiting for TUNID” (refer to Figure 9-2-1) 

7. UNID is set via Propose/Apply using the new MACID value 

8. Device transits to CONFIGURING mode 


Peau 


9-2.2 Reset Switch 


SRS 126 If a reset switch is provided on a safety device, the safety device shall execute a Safety 
Supervisor Type 2 reset (i.e. reset to out-of-box, but preserve the password). 
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10-1 


10-1.1 


Bridging Requirements for Safety 


Bridged Multi-Cast Connections 


When multi-cast connections are bridged between DeviceNet and other Non-DeviceNet 
networks, the safety-aware DeviceNet bridge shall translate the connections from three 
messages on DeviceNet to two connections on Non-DeviceNet Networks. 


The safety-aware DeviceNet bridge shall execute the 3-to-2 multi-cast safety connection 
translation by concatenating the safety data message and the time correction message at the 


bridge. Figure 10-1.1 shows the mapping of producers and consumers in a bridge. 


Figure 10-1.1 Non-DeviceNet to DeviceNet Bridge Example 


Multicast (DeviceNet bridge Multicast 


producer consumer 
bridge context 
Application Data + | = Application 
elcation HA, > P Time coraotion [KP Data >(—___» Applicat 
\J c~t Time Coordination pp Time correction moN XN = 
P << C)-—}—Time Coordination psa 


A non-certified DeviceNet Bridge needs to implement the following requirements when 
translating the single connection Data Message consisting of a Data&Time_Stamp section, and 
a Time_Correction section into a Data Message connection consisting of a Data&Time_Stamp 
section, and a separate Time_Correction Message connection. 


A non-certified DeviceNet Bridge, bridging a multi-cast production from a Non-DeviceNet 
network to a DeviceNet network shall forward a Data Message consisting of a 
Data&Time_Stamp section onto the DeviceNet network, once and only once, any time a Data 
Message is received from the Non-DeviceNet network consisting of a Data&Time_Stamp 
section, and a Time Correction section. 


A non-certified DeviceNet Bridge, bridging a multi-cast production from a Non-DeviceNet 
network to a DeviceNet network shall forward a Time_Correction Message onto the 
DeviceNet network, once and only once, any time a Data Message is received from the Non- 
DeviceNet network with a Time Correction section - MCast_Byte.Consumer_Num equal to a 
value other than 0x0. If the MCast_Byte.Consumer_Num is equal to 0x0 (Null 
Time_Correction section), the Time_Correction Message shall not be forwarded. 


The non-certified DeviceNet Bridge shall not translate a Time_Coordination Message. It is 
forwarded upon reception. 
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Figure 10-1.2 DeviceNet to Non-DeviceNet Bridge Example 


Multicast DeviceNet bridge Multicast 
producer consumer 
bridge context 
Application Data + Application 
daa P Time correction Pa o eae Ps ite 
c Time Coordination Wey | rieteters tics Py | 
LL Cc} P Time Coordination C 


A non-certified DeviceNet Bridge should use the following logic when translating the two Data 
Message and Time_Correction Message connections into a single Data Message connection. 
The single Data Message connection contains a Data&Time_Stamp section and a 
Time_Correction section. 


A non-certified DeviceNet Bridge, bridging a multi-cast Data Message and Time_Correction 
Message from a DeviceNet network to a Non-DeviceNet network shall send a Data Message 
consisting of a Data&Time_Stamp section and a Time Correction section onto the Non- 
DeviceNet network any time it receives a Data Message consisting of a Data&Time_Stamp 
section from the DeviceNet network. 


Every Time_Correction Message or Messages received from the DeviceNet network shall be 
orwarded once and only once in order, in the Time Correction section of the Non-DeviceNet 
Data Messages that are triggered by the reception of the DeviveNet Data Message. 


When sending a Data Message onto the Non-DeviceNet network, if there are no 
Time_Correction Messages to be forwarded, the previous Time_Correction section shall be 
sent with the MCast_Byte.Consumer_Num equal to 0x0 (Null Time_Correction section). 


For the case of the first Data Message being sent onto Non-DeviceNet before a DeviceNet 
Time_Correction Message has been received, a Time_Correction section of all 00’s shall be 
sent. 


The DeviceNet Bridge shall never create or modify Safety CRCs for the Data&Time_Stamp, 
Time_Correction, or Time_Coordination sections. 


The last router/bridge in a multi-hop connection shall convert the Forward_Open requests 
received from a higher-level network into the equivalent Safety Open request when the target is 
on DeviceNet. 


When processing a SafetyClose, if an intermediate node cannot find the connection that is to be 
closed (it may have timed out at the node), the SafetyClose request shall still be forwarded to 
downstream nodes or the target application. 
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10-1.2 


Connections Originating on Ethernet or other non-DeviceNet CIP networks 


When the Originator of the connection, shown on the left in Figure 10-1.3, is on Ethernet, the 
processing is as follows. 


Figure 10-1.3 Connection Origination on Ethernet or other non-DeviceNet CIP networks 


Originator Target 

Multicast DeviceNet bridge Multicast 

consumer producer 

bridge context 
Application 2) . Data + Application 
‘deta Ct) —~Time correction oad es Daley Ey ‘data 

| P Time Coordination 5G <¢— Time correction Py 
> CP Time Coordination mC 


¢ The Software must know that one of the nodes for this connection is on DeviceNet AND 
that the connection is of type Multi-cast 
¢ It then knows that the 3" connection point information must be filled out 
e Time Correction RPI value entered (a calculated multiple of the Data RPI) 
e Default parameters filled in 
© The standard T-to-O connection type set to Multi-cast 
e The T-to-O connection size is = Data size + Time Correction size (6) 
e The standard O-to-T connection type set to point-to-point 
e The O-to-T connection size is = Time Coordination size (6) 


e The originator does not need to do any size adjustments. The sizes for the standard 


connections are correct. 


¢ The bridge, upon receiving the ForwardOpen that contains a Safety Segment must 


e Recognize that the Connection request is a “SafetyOpen” 

¢ Open a Class 3 connection to the target node 

e Recognize that the T-to-O connection type is a Multi-cast 

¢ Subtract the 3“ connection point size from the standard T-to-O size and allocate 
resources for two consumer connections appropriately. 

e Allocate the resources for the single producer connection 

e Send the SafetyOpen over the class 3 connection 
¢ (initial request) Modify the Connection IDs to request all IDs be assigned by the 

target 
e Set up the IDs for the connections based on the values returned from the target. 


e The target, upon receiving the SafetyOpen must 


e Accept the Class 3 connection request 

e Route the SafetyOpen message to the Connection object via the Message Router 

e Analyze the Connection Parameters and recognize that this is a Multi-cast request 
e Error checks the T=>O, O=>T, and TC connection parameters 

e Verifies that connection IDs requested can be provided 

¢ Subtracts the 3“ connection point size from the standard T-to-O size and allocates 


resources for two producer connections appropriately. Connection IDs assigned from 
available resources (if possible). 
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10-1.3 


e Allocate the resources for the single consumer connection. Connection IDs assigned 
from available resources (if possible). 
e Allocates an available consumer_number 


e Sends the SafetyOpen response with selected consumer_number, connection IDs, and 
PID. 


Connections Originating on DeviceNet to Off-Link Targets 


When the Originator of the connection, shown on the right in Figure 10-1.4, is on DeviceNet, 
the processing is as follows: 


Figure 10-1.4 Connection Origination on DeviceNet 


Target Originator 
Multicast DeviceNet bridge Multicast 
producer consumer 
bridge context 
Application Data + Application 
ore ees Time correction me eae Dale ro aay 
AJ C Time Coordination pp Time correction C 


P—— Ce Time Coordination. pa 


¢ The Software must know that one or more of the nodes for this connection is on DeviceNet 


AND that the connection is of type Multi-cast 
¢ It then knows that the 3" connection point information must be filled out 
e Time Correction RPI value entered (a calculated multiple of the Data RPI) 
e Default parameters filled in 
e The standard T-to-O connection type set to Multi-cast 
e The T-to-O connection size is = Data size + Time Correction size (6) 
e The standard O-to-T connection type set to point-to-point 
e The O-to-T connection size is = Time Coordination size (6) 
e The originator must 
e Parse & analyze the connection path (provided by the software) to determine the 


target is off-link and that a SafetyOpen will be sent to an intermediary node (i.e. bridge). 


e Open a Class 3 connection request to the bridge Macld (obtained from the path) 
e¢ Recognize that the T-to-O connection type is Multi-cast 


¢ Subtract the 3“ connection point size from the standard T-to-O size and allocate buffers 


for two consumer connections appropriately. 

e Allocate the resources for the single producer connection 

e Assign the IDs for the single producer connection based on ID resources available, set 
this value in the O-to-T connection Id of the ForwardOpen. 

e Format and send a ForwardOpen explicit message to the Connection Manager object in 
the bridge node 

e Set up the IDs for the two consumer connection based on the values returned by the 
bridge. 

e The bridge, upon receiving the ForwardOpen must 

e Recognize that the Connection request message is a ForwardOpen with a Safety 

Segment in the path 


Nv 
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¢ Recognize that the T-to-O connection type is a Multi-cast 

¢ Subtract the 3“ connection point size from the standard T-to-O size and allocate buffers 
for two producer connections appropriately (if they don’t already exist from a previous 
connection). 

e Allocate the resources for the single consumer connection 

e Forward the message as an unconnected ForwardOpen 

e Allocate the IDs for the two producer connections based on available resources and 
return them to the originator (or provide the IDs already assigned). 

e Set the consumer ID based on the value from the ForwardOpen 

e Forward the connection request to the Target device 

e Set up these resources based on the sizes of the standard O-to-T and T-to-O connections. 

e The target, upon receiving the “ForwardOpen” must 

¢ Route the message to the Connection Manager 

e Analyze the Connection Parameters and recognizes that it is a Multi-cast request 

e Error checks the T=>O, O=>T connection parameters 

¢ Allocates the resources based on the O-to-T and T-to-O sizes (the 3“ connection point 
information is ignored), and allocates resources for single producer connection (if they 
don’t already exist from a previous connection). 

e Allocate the resources for the single consumer connection. Connection IDs assigned 
from available resources (if possible). 

e Allocates an available consumer number 


e Sends the FowardOpen response with selected consumer number, connection IDs, and 
PID. 


10-1.4 Multi-cast Connections Originating and Terminating on DeviceNet 
When both the originator and target are on DeviceNet, the following process is followed. 


Figure 10-1.5 Local DeviceNet Connections 


Target Originator 
Multicast ‘ Multicast 
producer DeviceNet consumer 
Application _ | »(Py_ Data ec > Application 
data data 
ei — Time correction: Cc x 
Cc Time Coordination F 


¢ The Software must know that one or more of the nodes for this connection is on DeviceNet 
AND that the connection is of type Multi-cast 
¢ It then knows that the 3" connection point information must be filled out 
e Time Correction RPI value entered (a calculated multiple of the Data RPI) 
e Default parameters filled in 
¢ The standard T-to-O connection type set to Multi-cast 
¢ The T-to-O connection size is = Data size + Time Correction size (6) 
¢ The standard O-to-T connection type set to point-to-point 
e The O-to-T connection size is = Time Coordination size (6) 
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e The DeviceNet originator must 
¢ Parse & analyze the connection path (provided by the software) to determine the 
target is on-link and that a SafetyOpen is sent directly to the target node. 
e Open a Class 3 connection request to the target MacId 
e Recognize that the T-to-O connection type is a Multi-cast 
¢ Subtract the 3" connection point size from the standard T-to-O size and allocate buffers 
for 2-consumer connections appropriately. 
e Allocate the resources for the 1-producer connection 
e Assign the Ids for the 1-producer connection based on ID resources available, set this 
value in the O-to-T connection Id of the SafetyOpen. 
e Format and send a SafetyOpen explicit message to the Connection object in the target 
node 
e Set up the Ids for the 2-consumer connection based on the values returned by the target. 
e The target node, upon receiving the SafetyOpen will 
e Route the message to the Connection object 
e Recognize a SafetyOpen message with the T-to-O connection type Multi-cast 
¢ Subtract the 3“ connection point size from the standard T-to-O size and allocate buffers 
for 2-producer connections appropriately (if they don’t already exist from a previous 
request). 
e Allocate the resources for the 1-consumer connection 
e Allocate the Ids for the 2-producer connections based on available resources and return 
them to the originator (or provide the Ids from the existing connections) 
e Set the consumer Id based on the value from the SafetyOpen 
Reply to the connection request with the chosen Network Ids 
Allocates an available consumer number 
Sends the FowardOpen response with selected consumer number, connection IDs, and 
PID. 


eee 


10-1.5 Multi-cast Connections Originating and Terminating on non-DeviceNet CIP 
Networks 


When both the originator and target are on non-DeviceNet networks, the following process is 
followed. These connections may or may not be through bridges or routers, but the result is the 
same. 


Figure 10-1.6 Multi-cast Connections on non-DeviceNet CIP Networks 


Target Originator 
Multicast CIP bridge Multicast 
producer consumer 
bridge context 
Application ph iP Data + »(C >(P Data + (Cc Application 
‘data Time correction Time correction ee ata: 
C <4—Time Coordination P <¢— C-<4———Time Coordination P 


e The Software must know that one or more of the nodes for this connection is not on 
DeviceNet 
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It then knows that the 3 connection point information can be set to default values 
e Default parameters filled in 
The standard T-to-O connection type set to Multi-cast 

= The T-to-O connection size is = Data size + Time Correction size (6) 
The standard O-to-T connection type set to point-to-point 
e The O-to-T connection size is = Time Coordination size (6) 


The CIP originator 


The originator does not need to do any size adjustments. The sizes for these connections 
are always correct. 

Allocate the resources for the single producer connection 

Assign the IDs for the single producer connection based on ID resources available, set 
this value in the O-to-T connection ID of the ForwardOpen. 

send the ForwardOpen message to the target node 

Set up the IDs for the consumer connection based on the values returned by the target. 


The target node, upon receiving the ForwardOpen will 


Route the message to the Connection Manager 

Recognize a T-to-O connection type Multi-cast 

The target does not need to do any size adjustments. The sizes for these connections are 
always correct. 

Allocate the resources for the single consumer connection 

Allocate the Ids for the two producer connections based on available resources and 
return them to the originator (or provide the IDs from the existing connections) 

Set the consumer ID based on the value from the ForwardOpen 

Allocates an available consumer number 

Sends FowardOpen response with selected consumer number, connection IDs, and PID. 
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A-1 Introduction 


This chapter of the CIP Safety Networks specification contains additions to CIP Engineering 
Units that are safety specific. At this time, no such additions exist. 
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B-1 Introduction 


This chapter of the CIP Safety Networks specification contains additions to the Status Codes 
that are safety specific. At this time, no such additions exist. 
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C-1 


C-2 


C-3 


Introduction 


This chapter of the CIP Safety Networks specification contains additions to the Data 
Management specifications that are safety specific. 


Safety Network Segment 
The Safety Connection Parameters Segment Type has been added to the CIP Network Segment 


definition as segment type 0x10 (resulting in a segment value of 0x50). The updated Network 
Segment definition is shown in Table C-2.1 below. 


Table C-2.1 Safety Network Segment Identifier 


Network Segment Type Network Segment Name 


0x50 Safety segment 


The format of the Safety Network Segment is shown in Table C-2.2. This segment type is in 
the range of Network Segment types, which contains a data size field. The Safety Segment 
Format parameter, the first parameter in the data area, indicates what data follows. 


Table C-2.2 Safety Network Segment Definition 


Byte Field Name Data Type Description 
Offset 
0 Segment Type BYTE Indicates Safety Network Segment 
(0x50) 
1 Network Segment Data BYTE Length of segment data to follow (in 
Length words) 
2 Safety Network Segment | USINT Indicates type of Safety Network 
Format Segment 


0 = Target format 

1 = Router format 
2 = EF Format 

3 — 255 = Reserved 


3thrun | Safety Network Segment | ARRAY of | Safety Network Segment data, defined 
Data octet by segment format. 


Safety Network Segment: Target Format (0x00) 


The Target Format, shown in Table C-3.1, is directed at the target of the connection. The 
overall segment size for the target format is 56 bytes or 28 words. The “Network Segment Data 
Length” parameter is 27 words (0x1B). 
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Figure C-3.1 Safety Network Segment: Target Format (0x00) 


Field Name 


Data Type 


Description 


Reserved 


Byte 


Pad 


Configuration CRC (SCCRC) 


UDINT 


CRC-S32 of target Config Data Segment. 
A value of 0 is an indicator that SCID check 
can be skipped. 


Configuration TimeStamp (SCTS) 


DATE_AND_TIME 


Time and Date stamp of the configuration. A 
value of 0 is an indicator that SCID check 
can be skipped. 6-byte value (Date: 2-bytes, 
Time: 4-bytes) 


Time Correction EPI UDINT Not used: 0 
When used: Time Correction Connection 
Instance:: EPI 
Time Correction Network Connection WORD Network Connection Parameters for the 
Parameters Time Correction connection. This field uses 
the same definition as the Network 
Connection Parameter within the Connection 
Manager object. 
When not used: 0 (Null) 
When used: Fixed, High Priority, Multi-cast 
Target_UNID (TUNID) Struct UNID of the Target device. This value is a 
UINT 10-byte value consisting of the Safety 
q ; Network Id (6 octets) and the Node Address 
10: octets (4-byte address) 
Originator UNID (OUNID) Struct UNID of the Originator device. This value is 
UINT a 10-byte value consisting of the Safety 
q Network Id (6 octets) and the Node Address 
10: octets (4-byte address) 
Ping_Interval_EPI_Multiplier UINT Number that defines the Ping_Count_Interval 
for the connection. Valid range of values is 
give by FRS235 
Time_Coord_Msg_Min_Multiplier UINT For Producing Connection Instance. Valid 
range is 0 to 7813. 
Network_Time_Expectation_Multiplier_ | UINT For Consuming Connection Instance. Valid 
range is 0 to 42969 
Timeout_Multiplier USINT Used by producer and consumer to timeout 
connections. Valid range | to 4 
Max_Consumer_Number USINT Value: 1 (Single-Cast), 2-15(Multi-cast) 
Connection Parameters CRC (CPCRC) UDINT CRC-S32 of target connection parameters in 
this request. 
Time Correction Connection ID UDINT Not Used: 0xFFFFFFFF 
When used: Time Correction Connection 
Instance:: Connection ID 
Safety Segment Fields 
covered by Connection 
Parameters CRC 
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Safety Network Segment: Router Format (0x01) 


The Router Format, shown in Table C-4.1, is directed at an intermediate router along the 
connection path when that router needs to know this is a Safety Forward_Open. Currently, only 
DeviceNet routers need this network segment directed to them. The Network Segment is 
applied to the subnet from which the connection request originated. Router Format Safety 
Network Segments will only appear in the Path portion of the Connection_Path of a Safety 
ForwardOpen. The overall segment size for the router format is 14 bytes or 7 words. The 
“Network Segment Data Length” parameter is 6 words. 


Figure C-4.1 Safety Network Segment: Router Format (0x01) 


Field Name Data Type Description 
Reserved Byte Reserved, value = 0. 
Time Correction UDINT Not Used: 0xFFFFFFFF 


Connection ID When used: Time Correction Connection Instance:: 


Connection ID 


Time Correction EPI UDINT Not used: 0 
When used: Time Correction Connection Instance:: 
EPI 
Time Correction WORD Network Connection Parameters for the Time 
Network Connection Correction connection. This field uses the same 
Parameters definition as the Network Connection Parameter 


within the Connection Manager object. 
Not used: 0 (Null) 
When used: Fixed, High Priority, Multi-cast 


Safety Network Segment: Extended Format (0x02) 


The EF Format is directed at the target of the connection and shown in the table below. 


FRS373 All EF Format safety connections shall be established using the Extended format 
safety network segment in a Forward _Open (EtherNet/IP, SERCOS III) or a SafetyOpen 
(DeviceNet). 


Field Name Data Type Description 


Reserved Byte Pad 

Configuration CRC (SCCRC) UDINT CRC-S32 of target Config Data Segment. 

A value of 0 is an indicator that SCID check 
can be skipped. 


Configuration TimeStamp (SCTS) DATE_AND_TIME | Time and Date stamp of the configuration. A 
value of 0 is an indicator that SCID check 
can be skipped. 6-byte value (Date: 2-bytes, 
Time: 4-bytes) 

Time Correction EPI UDINT Not used: 0 

When used: Time Correction Connection 
Instance:: EPI 


Time Correction Network Connection WORD Network Connection Parameters for the 
Parameters Time Correction connection. This field uses 
the same definition as the Network 
Connection Parameter within the Connection 
Manager object. 


When not used: 0 (Null) 
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Field Name Data Type Description 
When used: Fixed, High Priority, Multi-cast 
Target_UNID (TUNID) Struct UNID of the target device. This value is a 
UINT 10-byte value consisting of the Safety 
Niet Network Id (6 octets) and the Node Address 
10: octets (4-byte address) 
Originator UNID (OUNID) Struct UNID of the Originator device. This value is 
UINT a 10-byte value consisting of the Safety 
= . Network Id (6 octets) and the Node Address 
10: octets (4-byte address) 
Ping_Interval_EPI_Multiplier UINT Number that defines the Ping_Count_Interval 
for the connection. Valid range of values is 
give by FRS235 
Time_Coord_Msg_Min_Multiplier UINT For Producing Connection Instance. Valid 


range is 0 to 7813. 


Network_Time_Expectation_Multiplier_ | UINT 


For Consuming Connection Instance. Valid 
range is 0 to 42969 


Timeout_Multiplier USINT Used by producer and consumer to timeout 
connections. Valid range of | to 255 for 
HiAvailabilityFormat. 

Max_Consumer_Number USINT Value: 1 (Single-Cast), 2-15(Multi-cast) 

Max_Fault_Number UINT Used by both producers and consumers to 


determine how many erroneous packets can 
be dropped before a connection must be 
closed. 

Default = 5. 


A value of 0 indicates connections must be 
closed on any detected error. 


Connection Parameters CRC (CPCRC) UDINT 


CRC-S32 of target connection parameters in 
this request. 


Time Correction Connection ID! UDINT 


Not Used: 0xFFFFFFFF 


When used: Time Correction Connection 
Instance:: Connection ID 


Initial Time Stamp! UINT 


Used by Consumer to initialize 
Last_Time_Stamp_for_Rollover 


Consuming Originator sets to OXFFFF 


Initial Rollover Value! UINT 


Used by Consumer to initialize 
TS_Rollover_Count 


Consuming Originator sets to OxFFFF 


"These fields are NOT included in the CPCRC. 
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D-1 Introduction 


This chapter of the CIP Safety Networks specification contains additions to CIP Engineering 
Units that are safety specific. At this time, no such additions exist. 
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E-1 Introduction 
This appendix presents the details of the safety related CRCs used in the safety protocol. 


Table E-1.1 Properties of 8 Bit CRC (CRC-S1) 


CRC-S1 CRC-S2 CRC-S3 CRC-S4 CRC-S5 

Width 8 8 16 32 24 

Poly 0x37 Ox3b Ox080F OxEDB88320 OxSD6DCB 
Init! Variable Variable Variable Variable Variable 
Refin False False False False False 
RefOut False False False False False 
XorOut 0x00 0x00 0x0000 0x00000000 OxOOFFFFFF 
Check” Ox4C OxBF 0x9516 0x340BC6D9 


1 The initial values used for the runtime protocol are in Volume 5 chapter 2 for CRC-S1, 
CRC-S2, CRC-S3 and CRC-S5. The initial values used for CRC-S4 are in table E-3.1 

2 To generate the correct check values use OxFF as initial values for CRC-S1 and CRC-S2, 
OxFFFF for CRC-S3, OxFFFFFFFF for CRC-S4 and 0xOOFFFFFF for CRC-S5 . 


Where: 


WIDTH: This is the width of the algorithm expressed in bits. This is one less than the width of 
the Poly. 


POLY: This parameter is the poly. This is a binary value which is specified as a hexadecimal 
number. 


INIT: This parameter specifies the initial value of the register when the algorithm starts. This is 
the value that is to be assigned to the register in the direct table algorithm. In the table 
algorithm, we may think of the register always commencing with the value zero, and this value 
being XORed into the register after the N'th bit iteration 


REFIN: This is a boolean parameter. If it is FALSE, input bytes are processed with bit 7 being 
treated as the most significant bit (MSB) and bit 0 being treated as the least significant bit. If 
this parameter is TRUE, each byte is reflected before being processed. 


REFOUT: This is a boolean parameter. If it is set to FALSE, the final value in the register is 
fed into the XOROUT stage directly, otherwise, if this parameter is TRUE, the final register 
value is reflected first. 


XOROUT: This is a W-bit value that should be specified as a hexadecimal number. It is 
XORed to the final register value (after the REFOUT) stage before the value is returned as the 
official checksum. 


CHECK: This field is not strictly part of the definition, and, in the event of an inconsistency 
between this field and the other field, the other fields take precedence. This field is a check 
value that can be used as a weak validator of implementations of the algorithm. The field 
contains the checksum obtained when the ASCII string "123456789" is fed through the 
specified algorithm (i.e. 313233... (hexadecimal)). 
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Native CRCs Used 


It is important that the Native CRCs be of a different form and be calculated differently than 
the Safety CRCs . The following table shows the CRCs used in the networks that will support 
the safety protocol. The native CRCs are used for diagnostics. The native CRCs will not be 
considered as part of the safety function of the protocol. 


Table E-2.1 Native Generator Polynomials 


Network Native Generator Polynomial 


DeviceNet | g(xy=xlt ex ax 4x7 txt 4x? 4] 


EtherNet/IP 
SERCOS III 


g(xyaxr ex ex gx? gx exP gal gx gtx 4 txt tx txt 


ControlNet 


g(x) =x! +x? +2541 


All of the networks that support the safety protocol calculate the native CRC in the network 
interface chips or ASICs. The Safety CRCs will be calculated using different circuits, 
algorithms or software. 


CRC Usage Specifications 


The I/O messaging CRC usage is defined in Chapter 2 using CRC S1, CRC-S2, CRC-S3, and 
CRC-SS but there are a number of other CRCs defined in the safety protocol for connection 
establishment, configuration, and the Safety extension to the EDS file definition. Table E-3.1 
summarizes which algorithm is used and the starting seed value for each use. 


Table E-3.1 CRC Usage for Connection and Configuration 


CRC Name Algorithm Used Starting Seed Spec Description 
Value Reference 

SCCRC CRC-S4 OxFFFFFFFF Section Safety Configuration CRC 
(refer to example code) 2-10.3.2 

CPCRC CRC-S4 OxFFFFFFFF Section Connection Parameter CRC 
(refer to example code) 2- 10.3.6 

Password CRC_ | CRC-S4 0xFDFDFDFD Section 
(refer to example code) 7-114 before transmission 

EDS File CRC | CRC-S4 OxFDFDFDFD Section Used to provide integrity 
(refer to example code) 7-22.11 over EDS files used by 


safety devices 
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E-4 CRC Example Code 


#include "stdio.h" //for printf 
#include "memory.h" //for memcmp 


#define CRCS1_POLYNOMIAL 0x37 

#define CRCS2_POLYNOMIAL 0x3b 

#define CRCS3_POLYNOMIAL 0x080F 

#define CRC32_POLYNOMIAL Oxedb88320 // not 0x04C11DB7 
#define CRCSS_POLYNOMIAL 0x5D6DCB 


// CRC32 (CRC-S4) 

// polynomial Qxedb88320 = standard CRC-32 bit reversed from the regular 
// published polynomial of 0x04clldb7. This table should be used to 
// veplicate standard Ethernet CRC hardware algorithm. Thus the software 
// implementation of the Ethernet CRC should produce the same result as the 
// hardware. This table was generated via right shifting the LSB of each 
// byte 

const unsigned long CRC32Table[256] = 

{ 

0x00000000, 0x77073096, OxEEQE612C, 0x990951BA, 
0x076DC419, Ox706AF48F, 0xE963A535, 0x9E6495A3, 
0x0EDB8832, 0x79DCB8A4, OxEOD5E91E, 0x97D2D988, 
0x09B64C2B, 0x7EB17CBD, OxE7B82D07, 0x90BF1D91, 
0x1DB71064, Ox6ABO20F2, OxF3B97148, 0x84BE41DE, 
Ox1ADAD47D, Ox6DDDE4EB, OxF4D4B551, 0x83D385C7, 
0x136C9856, Ox646BA8CO, OxFD62F97A, Ox8A65C9EC, 
0x14015C4F, 0x63066CD9, OxFAQF3D63, 0x8D080DF5, 
0x3B6E20C8, 0x4C69105E, 0xD56041E4, 0xA2677172, 
0x3C03E4D1, 0x4B04D447, OxD20D85FD, OxA5OAB56B, 
Ox35B5A8FA, 0x42B2986C, OxDBBBC9D6, OxACBCF940, 
0x32D86CE3, 0x45DF5C75, OxDCD60DCF, 0xABD13D59, 
0x26D930AC, 0x51DE003A, OxC8D75180, OxBFD06116, 
0x21B4F4B5, 0x56B3C423, OxCFBA9599, OxB8BDASOF, 
Ox2802B89E, Ox5F058808, OxC60CD9B2, OxB10BE924, 
Ox2F6F7C87, 0x58684C11, OxC1611DAB, 0xB6662D3D, 
0x76DC4190, 0x01DB7106, 0x98D220BC, OxEFD5102aA, 
0x71B18589, Ox06B6B51F, Ox9FBFE4A5, 0xE8B8D433, 
0x7807C9A2, Ox0FOOF934, 0x9609A88E, 0xE10E9818, 
Ox7F6A0DBB, 0x086D3D2D, 0x91646C97, 0xE6635C01, 
Ox6B6B51F4, 0x1C6C6162, 0x856530D8, OxF262004E, 
0x6C0695ED, 0x1B01A57B, Ox8208F4C1, OxFS0FC457, 
0x65B0D9C6, 0x12B7E950, Ox8BBEB8EA, 0xFCB9887C, 
0x62DDIDDF, 0x15DA2D49, Ox8CD37CF3, OxFBD44C65, 
0x4DB26158, Ox3AB551CE, 0xA3BC0074, 0xD4BB30E2, 
Ox4ADFA541, 0x3DD895D7, OxA4D1C46D, OxD3D6F4FB, 
0x4369E96A, 0x346ED9FC, 0xAD678846, 0xDA60B8D0, 
0x44042D73, 0x33031DE5, OxAAOA4C5F, 0xDDOD7CC9, 
0x5005713C, 0x270241AA, OxBEOB1010, 0xC90C2086, 
0x5768B525, 0x206F85B3, 0xB966D409, OxCE61E49F, 
Ox5EDEF90E, 0x29D9C998, 0xB0D09822, OxC7D7A8B4, 
0x59B33D17, 0x2EB40D81, OxB7BD5C3B, OxCOBA6CAD, 
0xEDB88320, Ox9ABFB3B6, Ox03B6E20C, 0x74B1D29A, 
0xEAD54739, Ox9DD277AF, 0x04DB2615, 0x73DC1683, 
0xE3630B12, 0x94643B84, Ox0D6D6A3E, Ox7A6A5AA8, 
OxE40ECFOB, 0x9309FF9D, Ox0AQ0AE27, 0x7D079EB1, 
OxFOOF9344, 0x8708A3D2, OxlE01F268, 0x6906C2FE, 
OxF762575D, 0x806567CB, 0x196C3671, Ox6E6B06E7, 
0xFED41B76, 0x89D32BE0, Ox10DA7A5A, 0x67DD4ACC, 
OxF9B9DF6F, OxSEBEEFF9, 0x17B7BE43, 0x60BO8ED5, 
OxD6D6A3E8, O0xA1D1937E, Ox38D8C2C4, Ox4FDFF252, 
OxD1BB67F1, OxA6BC5767, Ox3FB506DD, 0x48B2364B, 
OxD80D2BDA, OxAFOA1B4C, 0x36034AF6, 0x41047A60, 
OxDF60EFC3, OxA867DF55, Ox316E8EEF, 0x4669BE79, 
OxCB61B38C, 0xBC66831A, 0x256FD2A0, 0x5268E236, 
0xCC0C7795, 0xBBOB4703, 0x220216B9, 0x5505262F, 
OxC5BA3BBE, 0xB2BD0B28, 0x2BB45A92, 0x5CB36A04, 
OxC2D7FFA7, OxBSDOCF31, 0x2CD99E8B, Ox5BDEAE1D, 
0x9B64C2B0, OxEC63F226, Ox756AA39C, 0x026D930A, 
0x9C0906A9, OxEBOE363F, 0x72076785, 0x05005713, 
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Ox95BF4A82, OxE2B87A14, 0x7BB12BAE, 0x0CB61B38, 
0x92D28E9B, OxESD5BEOD, Ox7CDCEFB7, Ox0BDBDF21, 
0x86D3D2D4, OxF1D4E242, Ox68DDB3F8, O0x1FDA836E, 
Ox81BE16CD, OxF6B9265B, Ox6FBO77E1, 0x18B74777, 
0x88085AE6, OxFFOF6A70, 0x66063BCA, 0x11010B5C, 
Ox8F659EFF, OxF862AE69, Ox616BFFD3, 0x166CCF45, 
OxAQOAE278, OxD7ODD2EER, 0x4E048354, 0x3903B3C2, 
0xA7672661, OxDO6016F7, 0x4969474D, 0x3E6E77DB, 
OXAED16A4A, OxD9D65ADC, Ox40DFOB66, 0x37D83BFO, 
OxA9BCAE53, OxDEBB9EC5, 0x47B2CF7F, 0x30B5FFE9, 
OxBDBDF21C, OxCABAC28A, 0x53B39330, 0x24B4A3A6, 
0xBAD03605, OxCDD70693, Ox54DE5729, 0x23D967BF, 
OxB3667A2E, OxC4614AB8, Ox5D681B02, 0x2A6F2B94, 
0xB40BBE37, 0xC30C8EA1, Ox5AQ5DF1B, 0x2D02EF8D 
Ye 


//CRCS3_POLYNOMIAL = 0x080F 

//This table was generated via left shifting the MSB of each byte 
const unsigned short CRC16Table[256] = 

{ 

0x0000, Ox080F, Ox101E, 0x1811, 0x203C, 0x2833, 0x3022, 0x382D, 
0x4078, 0x4877, 0x5066, 0x5869, 0x6044, O0x684B, Ox705A, 0x7855, 
Ox80F0, Ox88FF, Ox90EE, 0x98E1, OxAOCC, OxA8C3, OxBOD2, OxB8DD, 
0xC088, OxC887, 0xD096, 0xD899, OxEOB4, OxE8BB, OxFOAA, OxF8A5, 
Ox09EF, Ox01E0, Ox19F1, Oxl1FE, 0x29D3, 0x21DC, 0x39CD, 0x31C2, 
0x4997, 0x4198, 0x5989, 0x5186, 0x69AB, 0x61A4, 0x79B5, Ox71BA, 
Ox891F, 0x8110, 0x9901, 0x910E, 0xA923, OxA12C, 0xB93D, 0xB132, 
0xC967, 0xC168, OxD979, OxD176, OxE95B, OxE154, OxF945, OxF14A, 
0x13DE, 0x1BD1, 0x03C0, Ox0BCF, 0x33E2, Ox3BED, 0x23FC, 0x2BF3, 
0x53A6, Ox5BA9, 0x43B8, 0x4BB7, 0x739A, 0x7B95, 0x6384, Ox6B8B, 
0x932E, 0x9B21, 0x8330, Ox8B3F, 0xB312, OxBB1D, 0xA30C, 0xABO3, 
0xD356, OxDB59, OxC348, OxCB47, OxF36A, OxFB65, 0xE374, OxEB7B, 
0x1A31, 0x123E, Ox0A2F, 0x0220, 0x3A0D, 0x3202, 0x2A13, 0x221C, 
0x5A49, 0x5246, Ox4A57, 0x4258, Ox7A75, Ox727A, Ox6A6B, 0x6264, 
Ox9AC1, Ox92CE, Ox8ADF, 0x82D0, OxBAFD, OxB2F2, OxAAE3, OxA2EC, 
OxDAB9, OxD2B6, OxCAA7, OxC2A8, OxFA85, OxF28A, OxEA9B, 0xE294, 
Ox27BC, Ox2FB3, 0x37A2, Ox3FAD, 0x0780, Ox0F8F, Ox179E, Ox1F91, 
Ox67C4, Ox6FCB, Ox77DA, Ox7FD5, Ox47F8, Ox4FF7, Ox57E6, Ox5SFE9, 
OxA74C, OxAF43, OxB752, OxBF5D, 0x8770, Ox8F7F, 0x976E, Ox9F61, 
OxE734, OxEF3B, OxF72A, OxFF25, 0xC708, OxCFO7, OxD716, OxDF19, 
Ox2E53, Ox265C, Ox3E4D, 0x3642, OxOE6F, 0x0660, OxlE71, Ox167E, 
Ox6E2B, 0x6624, Ox7E35, 0x763A, Ox4E17, 0x4618, Ox5EO9, 0x5606, 
OxAEA3, OxA6AC, OxBEBD, 0xB6B2, Ox8E9F, 0x8690, 0x9E81, 0x968E, 
OxEEDB, OxE6D4, OxFEC5, OxF6CA, OxCEE7, OxC6E8, OxDEF9, OxD6F6, 
0x3462, Ox3C6D, 0x247C, 0x2C73, Ox145E, Ox1C51, 0x0440, Ox0C4F, 
Ox741A, 0x7C15, 0x6404, Ox6COB, 0x5426, 0x5C29, 0x4438, 0x4C37, 
0xB492, OxBC9D, OxA48C, OxAC83, Ox94AE, Ox9CAl1, 0x84B0, Ox8CBF, 
OxF4EA, OxFCE5, OxE4F4, OxECFB, 0xD4D6, OxDCD9, 0xC4C8, OxCCCT7, 
0x3D8D, 0x3582, 0x2D93, 0x259C, Ox1DB1l, Ox15BE, Ox0DAF, 0x05A0, 
Ox7DF5, Ox75FA, Ox6DEB, 0x65E4, Ox5DC9, 0x55C6, Ox4DD7, 0x45D8, 
OxBD7D, OxB572, OxAD63, OxAS6C, Ox9D41, 0x954E, Ox8D5F, 0x8550, 
OxFD05, OxF50A, OxED1B, 0xE514, 0xDD39, 0xD536, OxCD27, 0xC528 
Vie 


//CRCS1_POLYNOMIAL=0x37 

//This table was generated via left shifting the MSB of each byte 
const unsigned char CRC8Table37[256] = 

{ 

0x00, 0x37, Ox6e, 0x59, Oxdc, Oxeb, Oxb2, 0x85, 
Ox8f, Oxb8, Oxel, Oxd6, 0x53, 0x64, Ox3d, Ox0a, 
0x29, Oxle, 0x47, 0x70, Oxf5, Oxc2, 0x9b, Oxac, 
Oxa6, 0x91, Oxc8, Oxff, Ox7a, Ox4d, 0x14, 0x23, 
0x52, 0x65, Ox3c, Ox0b, Ox8e, Oxb9, Oxe0, Oxd7, 
Oxdd, Oxea, Oxb3, 0x84, 0x01, 0x36, Ox6f, 0x58, 
Ox7b, Ox4c, 0x15, 0x22, Oxa7, 0x90, Oxc9, Oxfe, 
Ox£4, Oxc3, Ox9a, Oxad, 0x28, Oxlf, 0x46, Ox71, 
Oxa4, 0x93, Oxca, Oxfd, 0x78, Ox4£, 0x16, 0x21, 
0x2b, Oxlc, 0x45, 0x72, Ox£7, Oxc0, 0x99, Oxae, 
Ox8d, Oxba, Oxe3, Oxd4, 0x51, 0x66, Ox3£, 0x08, 
0x02, 0x35, Ox6c, Ox5b, Oxde, Oxe9, Oxb0, 0x87, 
Oxf6, Oxcl, 0x98, Oxaf, Ox2a, Oxld, 0x44, 0x73, 
0x79, Ox4e, 0x17, 0x20, Oxa5, 0x92, Oxcb, Oxfc, 
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Oxdf, Oxe8, Oxbl, 0x86, 0x03, 0x34, Ox6éd, OxSa, 
0x50, 0x67, Ox3e, 0x09, Ox8c, Oxbb, Oxe2, Oxd5, 
Ox7f£, 0x48, Ox1l, 0x26, Oxa3, 0x94, Oxcd, Oxfa, 
Oxf0, Oxc7, Ox9e, Oxa9, Ox2c, Oxlb, 0x42, 0x75, 
0x56, Ox61, 0x38, Ox0f, Ox8a, Oxbd, Oxe4, 0xd3, 
Oxd9, Oxee, Oxb7, 0x80, 0x05, 0x32, Ox6b, Ox5Sc, 
Ox2d, Oxla, 0x43, 0x74, Oxfl, Oxc6, Ox9f, Oxa8, 
Oxa2, 0x95, Oxcc, Oxfb, Ox7e, 0x49, 0x10, 0x27, 
0x04, 0x33, Ox6a, OxSd, Oxd8, Oxef, Oxb6, 0x81, 
Ox8b, Oxbc, Oxe5, Oxd2, 0x57, 0x60, 0x39, 0x0e, 
Oxdb, Oxec, Oxb5, 0x82, 0x07, 0x30, 0x69, OxSe, 
0x54, 0x63, Ox3a, Ox0d, 0x88, Oxbf, Oxe6, Oxdl, 
Oxf2, Oxc5, Ox9c, Oxab, Ox2e, 0x19, 0x40, 0x77, 
Ox7d, Ox4a, 0x13, 0x24, Oxal, 0x96, Oxcf, Ox£f8, 
0x89, Oxbe, Oxe7, Oxd0, 0x55, 0x62, 0x3b, 0x0c, 
0x06, 0x31, 0x68, Ox5f, Oxda, Oxed, Oxb4, 0x83, 
Oxa0, 0x97, Oxce, Oxf9, Ox7c, Ox4b, 0x12, 0x25, 
Ox2f, 0x18, 0x41, 0x76, Oxf3, Oxc4, 0x9d, Oxaa, 
Ve 


//CRCS2_POLYNOMIAL = 0x3b 

//This table was generated via left shifting the MSB of each byte 
const unsigned char CRC8Table3b[256] = 

{ 

0x00, Ox3b, 0x76, Ox4d, Oxec, Oxd7, 0x9a, Oxal, 
Oxe3, Oxd8, 0x95, Oxae, Ox0f, 0x34, 0x79, 0x42, 
Oxfd, Oxc6, Ox8b, Oxb0, Oxll, Ox2a, 0x67, Ox5c, 
Oxle, 0x25, 0x68, 0x53, Oxf2, Oxc9, 0x84, Oxbf, 
Oxcl, Oxfa, Oxb7, 0x8c, Ox2d, 0x16, Ox5b, 0x60, 
0x22, 0x19, 0x54, Ox6f, Oxce, Oxf5, Oxb8, 0x83, 
Ox3c, 0x07, Ox4a, 0x71, Oxd0, Oxeb, Oxa6, 0x9d, 
Oxdf, Oxe4, Oxa9, 0x92, 0x33, 0x08, 0x45, Ox7Te, 
Oxb9, 0x82, Oxcf, Oxf4, 0x55, Ox6e, 0x23, 0x18, 
OxSa, 0x61, Ox2c, 0x17, Oxb6, Ox8d, Oxc0, Oxfb, 
0x44, Ox7f, 0x32, 0x09, Oxa8, 0x93, Oxde, Oxe5, 
Oxa7, Ox9c, Oxdl, Oxea, Ox4b, 0x70, 0x3d, 0x06, 
0x78, 0x43, Ox0e, 0x35, 0x94, Oxaf, Oxe2, O0xd9, 
Ox9b, Oxa0, Oxed, Oxd6, 0x77, Ox4c, Ox01, 0x3a, 
0x85, Oxbe, Oxf3, Oxc8, 0x69, 0x52, Oxlf, 0x24, 
0x66, OxSd, 0x10, Ox2b, Ox8a, Oxbl, Oxfc, Oxc7, 
0x49, 0x72, Ox3f, 0x04, Oxa5, 0x9e, Oxd3, Oxe8, 
Oxaa, 0x91, Oxdc, Oxe7, 0x46, Ox7d, 0x30, O0x0b, 
Oxb4, Ox8f, Oxc2, Oxf9, 0x58, 0x63, Ox2e, 0x15, 
0x57, Ox6c, 0x21, Oxla, Oxbb, 0x80, Oxcd, Oxf6, 
0x88, Oxb3, Oxfe, Oxc5, 0x64, Ox5f, 0x12, 0x29, 
Ox6b, 0x50, Oxld, 0x26, 0x87, Oxbc, Oxfl, Oxca, 
0x75, Ox4e, 0x03, 0x38, 0x99, Oxa2, Oxef, Oxd4, 
0x96, Oxad, Oxe0, Oxdb, Ox7a, 0x41, 0x0c, 0x37, 
Oxf0, Oxcb, 0x86, Oxbd, Oxlc, 0x27, Ox6a, 0x51, 
0x13, 0x28, 0x65, Ox5e, Oxff, Oxc4, 0x89, Oxb2, 
OxOd, 0x36, Ox7b, 0x40, Oxel, Oxda, 0x97, Oxac, 
Oxee, Oxd5, 0x98, Oxa3, 0x02, 0x39, 0x74, Ox4f, 
0x31, Ox0a, 0x47, Ox7c, Oxdd, Oxe6, Oxab, 0x90, 
Oxd2, Oxe9, Oxa4, 0x9f, Ox3e, 0x05, 0x48, 0x73, 
Oxcc, Oxf7, Oxba, 0x81, 0x20, Oxlb, 0x56, Oxé6d, 
Ox2f, 0x14, 0x59, 0x62, Oxc3, Oxf8, Oxb5S, 0x8e, 


// polynominal 0x5D6DCB 

// This table was generated via left shifting the MSB of each byte and appending an 
// additional byte to form a long word value. The MSB of the table value will 
// always be zero 

const unsigned long CRCS5Table[256] = 

{ 

0x00000000, 0x005d6dcb, Ox00badb96, 0x00e7b65d, 

Ox0028dae7, Ox0075b72c, 0x00920171, Ox00cfécba, 

0x0051b5ce, 0x000cd805, Ox00eb6e58, 0x00b60393, 

0x00796£29, 0x002402e2, Ox00c3b4bf, 0x009ed974, 

0x00a36b9c, 0x00£e0657, 0x0019b00a, 0x0044ddcl, 

0x008bb17b, 0x00d6dcb0, 0x00316aed, 0x006c0726, 

0x00£2de52, 0x00afb399, 0x004805c4, 0x0015680F, 

0x00da04b5, 0x0087697e, Ox0060d£23, 0x003db2e8, 
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Ox001bbaf3, 0x0046d738, 0x00a16165, 0x00fc0cae, 
0x00336014, Ox006e0ddf, 0x0089bb82, 0x00d4d649, 
0x004a0£3d, 0x001762£6, Ox00£0d4ab, 0x00adb960, 
0x0062d5da, 0x003£b811, 0x00d80e4c, 0x00856387, 
Ox00b8d16f, 0x00e5bca4, 0x00020af9, 0x005£6732, 
0x00900b88, 0x00cd6643, Ox002ad01e, 0x0077bdd5, 
0x00e964a1, 0x00b4096a, 0x0053b£37, 0x000ed2£c, 
0x00clbe46, 0x009cd38d, 0x007b65d0, 0x0026081b, 
0x003775e6, 0x006a182d, 0x008dae70, 0x00d0c3bb, 
0x001faf01, 0x0042c2ca, 0x00a57497, 0x00£8195c, 
0x0066c028, 0x003bade3, Ox00dclbbe, 0x00817675, 
0x004elacf, 0x00137704, Ox00£4c159, 0x00a9ac92, 
0x00941e7a, 0x00C973b1, Ox002ec5ec, 0x0073a827, 
0x00bcc49d, 0x00e1a956, 0x00061£0b, 0x005b72c0, 
Ox00c5abb4, 0x0098c67£, 0x007£7022, 0x00221de9, 
0x00ed7153, 0x00b01c98, 0x0057aac5, 0x000ac70e, 
0x002cc£15, 0x007la2de, 0x00961483, 0x00cb7948, 
0x000415£2, 0x00597839, Ox00bece64, 0x00e3a3af, 
0x007d7adb, 0x00201710, 0x00c7al4d, 0x009acc86, 
0x0055a03c, 0x0008cd£7, Ox00ef7baa, 0x00b21661, 
0x008£a489, 0x00d2c942, 0x00357£1f, 0x006812d4, 
0x00a77e6e, 0x00fal3a5, Ox001da5£8, 0x0040c833, 
0x00de1147, 0x00837c8c, 0x0064cad1, 0x0039a71a, 
0x00£6cba0, 0x00aba66b, 0x004c1036, 0x00117d£d, 
0x006eebcc, 0x00338607, 0x00d4305a, 0x00895d91, 
0x0046312b, 0x001b5ce0, Ox00fceabd, 0x00a18776, 
0x003£5e02, 0x006233c9, 0x00858594, 0x00d8e85f, 
0x001784e5, 0x004ae92e, Ox00ad5£73, 0x00£032b8, 
0x00cd8050, 0x0090ed9b, 0x00775bc6, 0x002a360d, 
0x00e55ab7, 0x00b8377c, 0x005£8121, 0x0002ecea, 
0x009c359e, 0x00C15855, 0x0026ee08, 0x007b83c3, 
0x00b4e£79, 0x00e982b2, Ox000e34ef, 0x00535924, 
0x0075513£, 0x00283cf4, Ox00cf8aa9, 0x0092e762, 
0x005d8bd8, 0x0000e613, 0x00e7504e, 0x00ba3d85, 
0x0024e4f1, 0x0079893a, 0x009e3£67, 0x00c352ac, 
0x000c3e16, 0x005153dd, 0x00b6e580, 0x00eb884b, 
0x00d63aa3, 0x008b5768, 0x006ce135, 0x00318cfe, 
0x00fee044, 0x00a38d8f, 0x00443bd2, 0x00195619, 
0x00878£6d, 0x00dae2a6, 0x003d54£b, 0x00603930, 
0x00af558a, 0x00£23841, 0x00158elc, 0x0048e3d7, 
0x00599e2a, 0x0004f3e1, 0x00e345bc, 0x00be2877, 
0x007144cd, 0x002c2906, 0x00cb9£5b, 0x0096£290, 
0x00082be4, 0x0055462f, 0x00b2£072, Ox00ef9db9, 
0x0020£103, 0x007d9cc8, 0x009a2a95, 0x00c7475e, 
Ox00faf5b6, 0x00a7987d, 0x00402e20, 0x001d43eb, 
0x00d22£51, 0x008£429a, 0x0068f4c7, 0x0035990c, 
0x00ab4078, O0x00£62db3, 0x00119bee, 0x004cf625, 
0x00839a9f, Ox00def754, 0x00394109, 0x00642cc2, 
0x004224d9, 0x001£4912, Ox00£8ff4f, 0x00a59284, 
0x006afe3e, 0x003793£5, 0x00d025a8, 0x008d4863, 
0x00139117, Ox004efcdc, 0x00a94a81, 0x00f4274a, 
0x003b4b£0, 0x0066263b, 0x00819066, 0x00dcfdad, 
0x00e14£45, Ox00bc228e, 0x005b94d3, 0x0006f918, 
0x00c995a2, 0x0094£869, 0x00734e34, 0x002e23Ef, 
Ox00b0fa8b, 0x00ed9740, 0x000a211d, 0x00574cd6, 
0x0098206c, 0x00c54da7, 0x0022fbfa, 0x007£9631 
ye 


/** GetCRC32Ethernet 


\par Purpose: 

CRC32 calculation routine for polynomial 0Oxedb88320 which is bit reversed 
from the regular polynomial of 0x04clldb7 thus the (cre >> 8) below 

is right shifted. 


\note 
Doing incremental cre calculation is done with providing the result 
from the previous block with preset. 


\note 
Restrictions: 
len > 0 
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pStart points to valid memory with at least len bytes in size 


\param Input: \b pStart Starting address to compute CRC over 
\param Input: \b len Number of bytes 
\param Input: \b preset Preset value for CRC 


ef 
unsigned long GetCRC32Ethernet (const void *pStart, int len, unsigned long preset) 
{ 

unsigned long cre = preset; 

unsigned char *buf = (unsigned char *)pStart; 


while (len-- > 0) 
{ 
unsigned char data8 = *buf++; 
cre = CRC32Table[(cre * data8) & Oxff] * (cre >> 8); 
t 
return crc; 
} //GetCRC32Ethernet 


/** ComputeCRCS1 


\par Purpose: 
CRC8 calculation routine for polynomial 0x37. 
Note that the CRC8Table37 was computed via left shift operations. 


\note 
Doing incremental cre calculation is done with providing the result 
from the previous block with preset. 


\note 
Restrictions: 
len > 0 
pStart points to valid memory with at least len bytes in size 


\par Scope: public 


\param Input: \b pStart Starting address to compute CRC over 
\param Input: \b len Number of bytes 
\param Input: \b preset Preset value for CRC 


\par Edit History: 
ee 
unsigned char ComputeCRCSl (const void *pStart, int len, unsigned char preset) 
i 

unsigned char crc = preset; 

unsigned char *buf = (unsigned char *)pStart; 


while (len-- > 0) 
{ 
ere = CRC8Table37[ (cre * *buft++)]; 
} 
return (crc); 
} //ComputeCRCS1 


/** ComputeCRCS2 


\par Purpose: 
CRC8 calculation routine for polynomial 0x3b. 
Note that the CRC8Table3b was computed via left shift operations. 


\note 
Doing incremental cre calculation is done with providing the result 
from the previous block with preset. 


\note 
Restrictions: 
len > 0 
pStart points to valid memory with at least len bytes in size 
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\par Scope: public 


\param Input: \b pStart Starting address to compute CRC over 
\param Input: \b len Number of bytes 
\param Input: \b preset Preset value for CRC 


\par Edit History: 
ey 
unsigned char ComputeCRCS2(const void *pStart, int len, unsigned char preset) 


{ 


unsigned char cre = preset; 
unsigned char *buf = (unsigned char *)pStart; 


while (len-- > 0) 
{ 
ere = CRC8Table3b[ (cre * *buft++)]; 
} 
return (crc); 
} //ComputeCRCS2 


/** ComputeCRCS3 


\par Purpose: 
CRC16 calculation routine for polynomial 0x080F. 


The CRC16Table was computed via left shift operations and thus will do 
a (cre << 8). 


\note 
Doing incremental cre calculation is done with providing the result 
from the previous block with preset. 


\note 
Restrictions: 
len > 0 
pStart points to valid memory with at least len bytes in size 


\param Input: \b pStart Starting address to compute CRC over 
\param Input: \b len Number of bytes 
\param Input: \b preset Preset value for CRC 


ni 
unsigned short ComputeCRCS3(const void *pStart, int len, unsigned short preset) 
{ 

unsigned short cre = preset; 

unsigned char *buf = (unsigned char *)pStart; 


while (len-- > 0) 
{ 
unsigned char data = *buf++; 
ere = CRC16Table[((cre >> 8) * data)] * (cre << 8); 
} 
return (cre); 
} //ComputeCRCS3 


/** ComputeCRCS3Ref4 


\par Purpose: 

Compute crc given 4 bytes of data and a preset for the crc. 
This assumes the input data is stored in native (little or big) 
endian format. 


\par Scope: public 


\param Input: \b data Value to compute CRC on 
\param Input: \b preset Preset value for CRC 


\par Edit History: 
wd 
unsigned short ComputeCRCS3Ref4 (unsigned long data, unsigned short preset) 
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[ee 


xp 


unsigned short ComputeCRCS3Ref2 (unsigned short data, 


{ 


[xe 


+7 


unsigned long ComputeCRCS24 (const void *pStart, 


{ 


/** 


unsigned short cre = preset; 


ere = CRC16Table[ (cre 
ere = CRC16Table[ (cre 
ere CRC16Table[ (cre 
ere = CRC16Table[ (cre 
return crc; 


ComputeCRCS3Ref2 


\par Purpose: 


Compute crc given 2 bytes of data and a preset for the crc. 
This assumes the input data is stored in native 


\par Scope: public 


\param Input: \b data 
\param Input: \b prese 


\par Edit History: 


>> 
>> 
>> 
>> 


fc 


8) * (datas0xff)] 
8) * ((data>>8) &0xff) ] 
8) * ((data>>16) &0xff) 


((data>>24) &0xff) 


] 
] 


> eo 


(cre 
(cre 
(cre 
(cre 


<< 
<< 
<< 
<< 


(little: or 


Value to compute CRC on 
Preset value for CRC 


unsigned short crc = preset; 
cre = CRC16Table[(crce >> 8) * (data&0xff) ] 
cre = CRC16Table[(crce >> 8) * ((data>>8) &0xff) ] 


return crc; 


ComputeCRCs5 


\par Purpose: 


big) endian format. 


unsigned short preset) 


(cre << 8); 


CRCS5 calculation routine for polynomial Ox5D6DCB. 
The CRCS5Table was computed via left shift operations and thus will do a (cre 
<< 8). 


\note 


(cre << 8); 


Doing incremental cre calculation is done with providing the result 
from the previous block with preset. 


\note 
Restrictions: 
len > 0 


pStart points to valid memory with at least len bytes in size. 


CRC value returned is a long with the MSB 


\param Input: \b pStar 
\param Input: \b len 
\param Input: \b prese 


+ 


5 


= 0 


Starting address to compute CRC over 


Number of bytes 


Preset value for CRC 


unsigned long cre = preset; 


unsigned long tem 
unsigned char *buf 


while (len-- > 0) 
{ 


unsigned char data 


(unsigned char *)pStart; 


*buft+; 


‘7 XOR data with CRC2, look up result, 
cre = CRCS5Table[((crc >> 16) * data) &0xff] 


} 


return (cre & Ox00ffffff); 


//ComputeCRCS5 
ComputeCRCS3Ref1 


\par Purpose: 


Compute cre given 1 bytes of data and a preset for the crc. 


\par Scope: public 


int len, 


(unsigned long) 


unsigned long preset) 


then XOR that with CRC; 
(ere << B); 
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\param Input: \b data Value to compute CRC on 
\param Input: \b preset Preset value for CRC 


\par Edit History: 
iti 
unsigned short ComputeCRCS3Refl (unsigned char data, unsigned short preset) 
{ 

unsigned short cre = preset; 

ere = CRC16Table[(crce >> 8) * data] * (cre << 8); 

return crc} 


//The following routines were used to generate the above tables. 

//Just as a sanity check, rerun the calculations and test that the 

//tables are correct 

unsigned char CRC8Table37Ref[256]; 

unsigned char CRC8Table3bRef [256]; 

unsigned short CRC16TableRef[256]; 

unsigned long CRC32TableRef[256]; 

unsigned long CRCS5TableRef [256]; 

//left shift MSB 

static void InitSafetyCRC8Table() 

{ 
unsigned short j; 
unsigned char i; 
unsigned char carry8= 
unsigned char entry8= 


/{CRCS1_POLYNOMIAL 
for (j = 0; j < 256; jtt) 
{ 


entry8 = static_cast<unsigned char>(j); 
for (i = 0; i < 8; ++i) 
{ 
carry8 = entry8 & 0x80; // carry8 is the most significant bit 
entry8 = entry8 << 1; 
if (carry8) // if carry8 is nonzero 
{ 
entry8 = entry8 * CRCS1_POLYNOMIAL; // XOR by CRC polynom 
} 
} 
CRC8Table37Ref[j] = entry8; 


} 

//CRCS2_POLYNOMIAL 

for (j = 0; j < 256; j++) 
{ 


entry8 = static_cast<unsigned char>(j); 
for (i = 0; i < 8; ++1) 
{ 
carry8 = entry8 & 0x80; // carry8 is the most significant bit 
entry8 = entry8 << 1; 
if (carry8) // if carry8 is nonzero 
{ 
entry8 = entry8 * CRCS2_POLYNOMIAL; // XOR by CRC polynom 
} 
} 
CRC8Table3bRef[j] = entry8; 


} 
} // end of initSafetyCRCTable8bit 


//left shift MSB 
static void InitSafetyCRC16Table() 
{ 
unsigned short j; 
unsigned char i; 
unsigned short carryl6=0; 
unsigned short entry16=0; 


for (j = 0; j < 256; 4++) 
{ 
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entryl6 = 3; 
for (i = 0; i < 16; ++i) 
{ 
carryl6 = entryl6 & 0x8000; // carryl6 is the lowest 
// significant bit 
entryl6 = entryl6 << 1; 


if (carryl6) // if carryl6 is nonzero 
{ 
entryl6 = entryl6 * CRCS3_POLYNOMIAL; // XOR by CRC polynom 
} 
} 
CRC16TableRef[j] = entry16; 


t 
} // end of initSafetyCRC1éTable() 


//cight shift LSB 
static void InitSafetyCRC32Table() 


{ 


unsigned long 3; 
unsigned char i; 
unsigned long carry32=0; 
unsigned long entry32=0; 


//right shift 
for (j = 0; j < 256; j++) 


{ 


} 


entry32 = 3; 
for (i = 07 i < 6} ++i) 
{ 
carry32 = entry32 & 1; // carryl16 is the lowest 
// significant bit 


entry32 = entry32 >> 1; 
if (carry32) // if carryl6 is nonzero 
{ 
entry32 = entry32 * CRC32_POLYNOMIAL; // XOR by 
// CRC polynom 
} 


} 
CRC32TableRef[j] = entry32; 


} // end of initSafetyCRC32Table() 


//left shift MSB 
static void InitSafetyCRCS5Table() 


{ 


unsigned short 4; 
unsigned char i; 

unsigned long carry24=0; 

unsigned long entry24=0; 

unsigned long poly = unsigned long(CRCS5_POLYNOMIAL) ; 


for (j = 0; j < 256; j++) 


5 


bit 


t 


entry24 = (j<<16); 
for (i O; i < 8; ++i) 
{ 
carry24 = entry24 & 0x800000; // carry24 is the most significant 
entry24 = entry24 << 1; 
if (carry24) // if carry24 is nonzero 
{ 
entry24 = entry24 * poly; // XOR by CRC polynom 
} 
} 
CRCS5TableRef[j] = entry24 & 0x00ffffff; // Upper byte is don't care 


} // end of initSafetyCRCS5Table () 


//This is the reference model that the table driven routine must match 
unsigned char Crce8ComputeSlow(const void* buffer, unsigned int count, unsigned 
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char poly, unsigned char preset) 


{ 


} 


const unsigned char* ptr = (const unsigned char *) buffer; 
unsigned char crc8=preset; 
unsigned char value=0; 


while (count--) 


{ 


value = *ptrt++; 
crc8 *= value; 
for (int i = 0; i < 8; itt) 


{ 
if (crce8 & 0x80) 
{ 
erc8 = (crc8 << 1) * poly; 
} 
else 
{ 
eres <<= 1; 
} 
} 
} 
return crce8; 
//Crc8ComputeSlow 


//This is the reference model that the table driven routine must match 


unsigned short Crcl6ComputeSlow(const void* buffer, unsigned int count, 


short poly, unsigned short preset) 


{ 


const unsigned char* ptr = (const unsigned char *) buffer; 
unsigned short crcl6=preset; 
unsigned short value=0; 


while (count--) 
{ 
value = *ptrt+t; 
ercl6 *= (value << 8); 
for (int i = 0; i < 8; i++) 
{ 
if (crcl16 & 0x8000) 
{ 


} 


else 


{ 


ercl6 = (crcl6 << 1) * poly; 


ercl6 <<= 1; 
} 
} 
} 
return crcl6; 
//Crol6ComputeSlow 


//This is the reference model that the table driven routine must match 


unsigned long Crce32ComputeSlow(const void* buffer, unsigned int count, unsigned 


long poly, unsigned long preset) 


{ 


const unsigned char* ptr = (const unsigned char *) buffer; 
unsigned long crc32=preset; 
unsigned long value=0; 


while (count--) 


{ 


value = *ptrt++; 
crce32 *= (value); 
for (int i = O07; i < 8; i++) 


{ 
if (cra32 & 1) 
{ 
cere32 = (cre32 >> 1) * poly; 
} 
else 
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erc32 >>= 1; 


} 
} 
return crce32; 
} //Cxrce32ComputeSlow 


//This is the reference model that the table driven routine must match 
unsigned long CRCS5ComputeSlow(const void* buffer, unsigned int count, 
long poly, unsigned long preset) 
{ 
const unsigned char* ptr = (const unsigned char *) buffer; 
unsigned long CRCS5 = preset; 
unsigned long value=0; 


while (count--) 
{ 
value = *ptr+t+; 
CRCSS *= (value << 16); 
for (int i = 0; i < 8; it+) 
4 
if (CRCSS & 0x800000) 


{ 
CRCS5 = (CRCS5 << 1) * poly; 


CRCSS <<= 1; 


return (CRCSS & OxOOffffff); 
} //CRCS5ComputeSlow 


//define a structure such that it is 9 bytes long in packed format 
//so as to equal the cre test string length (in DoCrcTest below) 
struct SomeStruct 
{ 

unsigned char aBytel; 

unsigned char aByte2; 

unsigned char aByte3; 

unsigned short aShort; 

unsigned long aLong; 


int DoCrcTest () 


const char *string = "123456789" 
int len = 9; //length of "123456789" 
unsigned long crc32; 

unsigned short crcl6; 

unsigned char crc8; 

SomeStruct aStruct; 


//£i11 aStruct with equivalent to "123456789" in 
//little endian memory order 


aStruct.aBytel = 0x31; 
aStruct.aByte2 = 0x32; 
aStruct.aByte3 0x33; 
aStruct.aShort = 0x3534; 
aStruct .aLong 0x39383736; 


int crcMatch = 0; 


//the slow methods serve as the reference implementation 
/fall other optimizations (ie table driven) must match these 
crce8 = Crce8ComputeSlow(string, len, CRCS1_POLYNOMIAL, Oxff); 
if (crc8 != 0x4C) 

{ 


unsigned 
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exrcMatch |= 1; 
} 
crc8 = Crc8ComputeSlow(string, len, CRCS2_POLYNOMIAL, Oxff); 
if (crc8 != 0xBF) 
{ 


} 

crel6 = Crcl6ComputeSlow(string, len, CRCS3_POLYNOMIAL, Oxffff) ; 
if (crcl6 != 0x9516) 

{ 


ercMatch |= 2; 


crcMatch |= 4; 
} 


cre32 = Crc32ComputeSlow(string, len, CRC32_POLYNOMIAL, Oxffffffff); 
if (crc32 != 0x340bc6d9) 


{ 
crcMatch |= 8; 


t 


crc8 = ComputeCRCS1(string, len, Oxff); 


if (erc8 != 0x4C) 
ercMatch |= 0x10; 
t 
cre8 = ComputeCRCS2 (string, len, Oxff); 
if (crc8 != 0xBF) 
{ 


ercMatch |= 0x20; 


crcel6 = ComputeCRCS3 (string, len, Oxffff); 
if (crcl6 != 0x9516) 


{ 
ercMatch |= 0x40; 


t 


cre32 = GetCRC32Ethernet (string, len, Oxffffffff); 
if (erc32 != 0x340bc6d9) 
{ 
ercMatch |= 0x80; 
} 


//retest that the tables are correct 


InitSafetyCRC8Table(); 

InitSafetyCRC16Table(); 

InitSafetyCRC32Table(); 

if (memcmp (&CRC8Table37Ref[0], &CRC8Table37[0], 256) != 0) 
: ercMatch |= 0x200; 

ks (mememp (&CRC8Table3bRef[0], &CRC8Table3b[0], 256) != 0) 
‘ ercMatch |= 0x400; 

es (memcmp (&CRC16TableRef[0], &CRC16Table[0], 512) != 0) 

: ercMatch |= 0x800; 

i (mememp (&CRC32TableRef[0], &CRC32Table[0], 1024) != 0) 
‘ crcMatch |= 0x1000; 


} 


//should work on both big and little endian machine 


ercl6é = Oxffff; 

ecrcl6 = ComputeCRCS3Refl(aStruct.aBytel, crcl6); 
ercl6 = ComputeCRCS3Refl(aStruct.aByte2, crcl6); 
crel6é = ComputeCRCS3Refl(aStruct.aByte3, crcl6); 
crcl6 = ComputeCRCS3Ref2(aStruct.aShort, crcl6); 
crcl6 = ComputeCRCS3Ref4(aStruct.aLong, crcl6); 
if (crcl6 != 0x9516) 


{ 
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ercMatch |= 0x2000; 
t 


return creMatch; 
be 


int main(int argc, char* argv[]) 
{ 
int result = DoCrcTest (); 
if (result==0) 
printf("Tests passed! \n"); 
else 
printf("Tests failed, result = 0x%x\n",result); 
return result; 
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F-4.12 TST96 - EDS File Requirements 
F-4.13. TST97 - Safety Manual Inspection Requiremen 
F-4.14 TST98 - Requirements Not Tested at this time.. 
F-4.15 | TST12 - Origination of Off-link Connection Test .. 
F-4.15.1 Test Numbers Removed. 
F-5 — Safety Test Matrix. a 
F-5.1 Safety: Test Matrixs ret Sate ci dui Rete ot lcd Oise tite haed cide dded eee MbeciMes tlded tetas dT 
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F-1 


F-2 


F-2.1 


F-2.2 


Introduction 


This document describes tests and test procedures which can be used to qualify a device that 
implements the Safety Protocol for DeviceNet and EtherNet/IP Safety to levels up to and 
including Edition 2.2. Each test lists the requirements defined in Volume 5 that would be 
confirmed by the test. Every requirement in Volume 5 has been mapped to a test in this 
document. Not all devices will implement all aspects of the protocol, so each developer will 
need to determine which tests apply. A function-versus-test table is provided in Section F-5 to 
allow implementers to determine which tests should be run for their devices. For example, 
some devices may not initiate connections, so they would not need to test the connection 
originator capability. EtherNet/IP devices may not implement some of the functions that are 
DeviceNet specific, so they would exclude those related tests and vice-versa. 


This document will not make assumptions about how these tests will get created or how they 
will operate. The focus will be on “what” tests need to be performed and not “how”. 
However, every effort has been made to identify tests or methods that can be easily facilitated 
by automated test methods. The suggested test procedures described here are intentionally 
kept general to allow the test developer more freedom to refine the test or add more detailed 
steps. 


Some of the tests that will be required in this document cannot be verified via black box 
testing. These tests will be identified as White Box Tests. It is the responsibility of the product 
company to document procedures for these tests during development. 


[his document is organized by major functionality to allow developers to quickly isolate the 
they will need to focus on for their product. 


Scope 


Chis document will define tests for products that implement the safety protocol on networks 
DeviceNet and EtherNet/IP. 


x 


'unctional tests 


ie purpose of functional testing is to verify that the DUT(s) function as described in this 
specification. 


Example: Verify proper behavior of Safety Connection Types. 


DUTs 


The DUTs covered in this test document are the following: 


e Any Safety Output device that utilizes the DeviceNet or EtherNet/IP Safety Protocol 
e Any Safety Input device that utilizes the DeviceNet or EtherNet/IP Safety Protocol 
e Any Safety Controller device that utilizes the DeviceNet or EtherNet/IP Safety Protocol 
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F-2.2.1 


F-2.2.2 


F-2.3 


Functionality 


Refer to the Subsections of this document for the functionality that will be tested. Each 
requirement in Volume 5 has been listed under either a Black Box Test or a White Box Test to 
verify that functionality. It is the responsibility of either the Product Developer or the Safety 
Functional Test software to ensure that functionality is thoroughly tested. Test suites will be 
written for tests in the Black Box category. The degree to which these tests can be automated 
is yet to be determined since some tests require the tester to make visual confirmations. 


Point-to-point Test Configuration 


The large majority of black box functional testing can be accomplished with test software 
running on a PC through a DeviceNet interface card or EtherNet/IP NIC card to the D.U.T. 
Figure below shows this basic configuration. This configuration applies whether the PC is 
initiating a communication transaction or D.U.T. is initiating a communication transaction. 

The software may change, but the basic one-on-one interface will stay the same. Tests that use 
this configuration will refer to it as: 


Configuration: PTP 


Figure F-2.1 Safety Network Point-to-point Test Configuration 
a, 


Test 
Software 


DeviceNet or EtherNet/IP 


System Tests 


The main purpose is to ensure that the product interfaces interact correctly with other Safety 
devices, such as Safety Controllers, Safety I/O, and Safety devices interacting either directly or 
through Bridges or Routers. Another purpose of system testing is to verify that the DUT 
operates or co-exists peacefully with standard products on a CIP network; that it doesn’t 
interfere with standard devices and standard devices don’t interfere with it. Most of the “Black 
Box” tests defined in this document can be considered System tests. 


Example: Connection Establishment and Safety I/O data exchange. 
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F-2.3.1 


F-2.4 


F-3 


F-3.1 


Test Conformance Strategy 


To be able to show conformance to the protocol, all devices will execute an appropriate “set” of 
the system tests defined in this specification. When the test software indicates that all the 
required tests have passed, there is a need to have the tester make a positive confirmation via 
the test log files that the tests did in fact run correctly. A method will be employed in all tests 
that allow a tester to easily confirm that the tests were executed properly by inspecting the log 
files. 


e Every Black Box test shall identify one or more “test milestones” that must be reached to 
successfully complete the test. 

e Every Black Box test shall insert a special text string into the log file when the test results 
of each test are written to the log. This string shall contain at a minimum, the test number, 
milestone number, milestone name, and results indication. 

e Every Black Box test shall document a pre-calculated “golden” CRC value of the 
“successful” milestone text strings concatenated in their anticipated order to represent a 
successful test execution. 
e Every Black Box test shall provide a CRC calculation of the milestone text strings that are 
generated during the test. The final CRC value shall be inserted into the log file at the end 
of the test. The tester will be instructed to compare this value to the documented “golden 
value” to verify successful execution. 

e The CRC calculation used shall be the Ethernet/IP CRC-32 algorithm defined in the Safety 
Functional Spec appendix C, with an initial seed value of OxFD FD FD FD. 

e Many tests require verification that Extended Format packets were dropped when errors are 
injected. The method used to determine this is by inspecting the Producer/Consumer Fault 
Count attribute of the Safety Validator object. The attribute should increment for each 
dropped packet on that connection. 


Subsystem tests - White Box Tests 


The purpose of subsystem testing is to verify that specific functions interact correctly with 
other functions. Because of the nature of these tests, they need to be performed by the 
developer and confirmed as part of firmware qualification testing (ie. Module testing). 


Example: Safety Validator interface to the device application. 
Black Box Tests 


Safety Protocol Test Engine 


The Safety Protocol Test Engine (SPTE) is a PC-based testing application that uses a set of 
input variables to configure the engine. This test engine will serve as a primary initial 
condition for all the DUT positive and negative test procedures for both Targets and 
Originators. This test engine will be the means by which communication between the Tester 
and DUT gets established. If the DUT is operating without error while interacting with this 
engine, the engine will run continuously. 


This test engine can be configured to simulate either an originator or a target. The inputs to the 
test engine control features such as, originator emulation vs. target emulation, producer vs. 
consumer connections, multi-cast vs. single-cast, data sizes, EPI, etc. A complete list of the 
controls will be provided in a separate user manual. 
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F-3.2 


F-3.3 


TST1 - Standard DeviceNet Behavior 


All DeviceNet safety devices are required to execute the standard test suite of CIP tests to 
assure that basic CIP functionality is executed correctly. For example, DeviceNet safety 
devices must perform the Duplicate Mac ID test on start-up. 


Requirement 5 
Niles Requirement 

SRS102 Devices implementing DeviceNet Safety shall support attributes 11 of the DeviceNet 
object. 

SRS106 The Macld attribute (if supported) in the DeviceNet object shall always reflect the value in 
use. 

SRS110 When the switches are read, if the switches specify a valid MAC ID, (a value from 0 to 63 
for MAC ID), this value shall be used as the MAC ID. 

SRS113 When the switches are read, if the switches used to specify the MACID are set to a valid 
value (a value from 0 to 63), the MACID attribute shall have Get Only access. 

SRS114 When the switches are read, if the switches are set to the software programmable mode 
(>63 for the MAC ID), the MACID attribute shall have Set access. 

SRS121 If the device is out-of-box it shall use the current MAC ID switch settings if these are valid 
values 

FRS14 Each safety device shall have a single physical address that is unique on the devices 
network segment. 

FRSI5 The safety network shall not restrict any physical topologies 


TST1 DeviceNet Safety Devices shall be confirmed as being compliant to Standard DeviceNet 
by running the standard DeviceNet conformance test suite. 


TST49 - DeviceNet Object Tests 


The requirements previously allocated to TST49 are covered by the Standard 
conformance test for the DeviceNet object 


TST107 - Standard EtherNet/IP Behavior 


All EtherNet/IP safety devices are required to execute the standard test suite of CIP tests to 
assure that basic CIP functionality is executed correctly. 


ee een 

SRS209 Devices implementing EtherNet/IP Safety shall support attribute 7 of the TCP/IP object. 

FRS14 Each safety device shall have a single physical address that is unique on the devices network 
segment. 

FRS15S The safety network shall not restrict any physical topologies 


TST107 EtherNet/IP Safety Devices shall be confirmed as being compliant to Standard 
EtherNet/IP by running the standard EtherNet/IP conformance test suite. 


The standard EtherNet/IP test suite will confirm the support for Attribute 7 of TCP/IP object 
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F-3.4 Basic Connection Establishment 


This section will define tests related to establishing non-configuring connections to safety 
nodes. Because of the Peer-to-peer nature of Safety I/O connections, both client-side and 
server-side connection tests need to be defined. Client side connection tests require that the test 
software act as connection server, with the ability to generate various replies that will test the 
error handling ability of the client-side. These tests will all use the PTP test configuration. 


This test plan covers both DeviceNet and EtherNet/IP DUTs. All black box tests defined in 
this specification (from the DUT perspective) can be run with the PTP test configuration (i.e. 
the operation of the bridge in these tests is not currently covered by these tests). 


F-3.4.1 Type 2 Connection Reception by Targets 
F-3.4.1.1 TST2 - Positive Type 2 Connection Establishment Test 


This test is a positive test that confirms a set of requirements by virtue of the fact that the target 
DUT processes and responds without error to SafetyOpen requests. No configuration 
functionality is confirmed in this test. The test will validate the responses received. 


Requirement ni 
Maa Requirement 

FRS153 All CIP Safety connections shall be established using a Forward_Open with a safety 
network segment (EtherNet/IP, SERCOS III) or a SafetyOpen (DeviceNet) 

FRS163 The SCID = 0 in a Type 2b SafetyOpen shall have special meaning to indicate that the 
SCID shall not be checked by a target before accepting the connection. 

FRS164 If the TUNID to UNID comparison is successful than the SafetyOpen destination is 
deemed to be correct and processing shall continue. 

FRS174 Successful SafetyOpen responses shall return the connection identifiers used, as well as 


the Consumer_Number assigned to the originator (always OxFFFF for single-cast 
connections). 

FRS345 The T-to-O API, O-to-T API, and Time Correction API in a success response shall 
always be the same value received in the SafetyOpen 


SRS2 Type 2a: When a target receives a Type 2 SafetyOpen (no configuration data) 
accompanied by a non-zero Safety Configuration ID (SCID = SCCRC+SCTS), it shall 
compare it against the SCID of the configuration and only accept the connection if they 
match. 


SRS98 If the target has allocated identifiers from its pool, it shall insert them into the 
SafetyOpen success response. 


SRS180 A target device that has an existing configuration shall (at a minimum) do the following 
when a type 2a or 2b Safety Open is received. 


¢ — If the connection path is to an output resource, verifies that the OUNID in the 
SafetyOpen matches the OUNID for the connection, 


e If the SCID is non-zero, confirm the SCID matches the device SCID 
¢ — Verify that the TUNID in the SafetyOpen matches the device TUNID 
e Verify the Electronic Key matches the device 
e — Verify the CPCRC over the configuration is correct, 
e Verify and validate the connection parameters, 

e Validate the application path 

¢ Confirm the safety connection requested is supported 

e Safety parameters are within valid ranges 


¢ — Transition the connection to the established state 
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TST2 The Type 2 Positive Connection Establishment test shall confirm that the target DUT 
meets a core set of requirements by virtue of the fact that successfully accepted a properly 
formed SafetyOpen and sent a proper formed success response. 


Required Initial Conditions: 
1. Run SPTE as an originator. 
Test Procedure: 


Establish a connection with an SCID equal to the DUT SCID 
Confirm a positive SafetyOpen response is received 
Test will inspect the SafetyOpen Response and confirm the parameters are correct 


Confirm the O-to-T API, T-to-O API and Time Correction API all match what was sent 
in the SafetyOpen 


Pee be 


Establish a connection with a zero SCID 
Confirm a positive SafetyOpen response is received 
Test will inspect the SafetyOpen Response and confirm the parameters are correct 


Confirm the O-to-T API, T-to-O API and Time Correction API all match what was sent 
in the SafetyOpen 


ot nn 


9. Test will inspect the SafetyOpen Response and confirm the parameters are correct 
10. Close connection 


F-3.4.1.2 TST113 - Positive Type 2 Test for Extended Format connections 


This test is a positive test that confirms a set of requirements by virtue of the fact that the target 
DUT processes and responds without error to SafetyOpen requests using the Extended Format. 
No configuration functionality is confirmed in this test. The test will validate the responses 


received. 
Requirement * 
Number Requirement 

FRS153 All CIP Safety connections shall be established using a Forward_Open with a safety 
network segment (EtherNet/IP, SERCOS IID or a SafetyOpen (DeviceNet) 

FRS164 If the TUNID to UNID comparison is successful than the SafetyOpen destination is 
deemed to be correct and processing shall continue. 

FRS174 Successful SafetyOpen responses shall return the connection identifiers used, as well as 
the Consumer_Number assigned to the originator (always OxFFFF for single-cast 
connections). 

FRS345 The T-to-O API, O-to-T API, and Time Correction API in a success response shall 
always be the same value received in the SafetyOpen 

SRS2 Type 2a: When a target receives a Type 2 SafetyOpen (no configuration data) 
accompanied by a non-zero Safety Configuration ID (SCID = SCCRC+SCTS), it shall 
compare it against the SCID of the configuration and only accept the connection if they 
match. 

SRS98 If the target has allocated identifiers from its pool, it shall insert them into the 
SafetyOpen success response 

SRS180 A target device that has an existing configuration shall (at a minimum) do the following 
when a type 2a or 2b Safety Open is received. 

e If the connection path is to an output resource, verifies that the OUNID in the 
SafetyOpen matches the OUNID for the connection, 
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a caeness Requirement 
¢ — If the SCID is non-zero, confirm the SCID matches the device SCID 
e — Verify that the TUNID in the SafetyOpen matches the device TUNID 
* Verify the Electronic Key matches the device 
e — Verify the CPCRC over the configuration is correct, 
¢ — Verify and validate the connection parameters, 
e — Validate the application path 
e¢ Confirm the safety connection requested is supported 
* — Safety parameters are within valid ranges 
¢ Transition the connection to the established state 
FRS373 All EF safety connections shall be established using the Extended format safety network 
segment in a Forward_Open (EtherNet/IP, SERCOS III) or a SafetyOpen (DeviceNet). 
FRS362 When the Target of a connection using the extended format on DeviceNet, it shall use 
the 22-byte extended format SafetyOpen Target Application reply. 
FRS363 When the Target of a connection using the extended format on EtherNet/IP, it shall use 
the 14-byte extended format SafetyOpen Target Application reply. 


TST113 The Type 2 Extended Format Connection Establishment test shall confirm that the 
target DUT meets a core set of requirements by virtue of the fact that successfully accepted a 
properly formed SafetyOpen and sent a proper formed success response. 


Required Initial Conditions: 


1, Run SPTE as an originator of EF connections. Both DUT producing and consuming 
connections must be tested. 


Test Procedure: 


3. Establish a single-cast output connection (DUT is consumer) with the EF segment type 
and a SCID equal to the DUT SCID 

4. Confirm a positive SafetyOpen response is received in the base response format 

5. Test will inspect the SafetyOpen Response and confirm the parameters are correct 


Confirm the O-to-T API, T-to-O API and Time Correction API all match what was sent 
in the SafetyOpen 


Ts Establish a Multi-cast input connection (DUT is producer) with the EF and a SCID equal 
to the DUT SCID 


Confirm a positive SafetyOpen response is received with proper EF response format 
Test will inspect the SafetyOpen Response and confirm the parameters are correct 


10. Confirm the O-to-T API, T-to-O API and Time Correction API all match what was sent 
in the SafetyOpen 


11. Test will inspect the SafetyOpen Response and confirm the parameters are correct 


12. Close connection 


F-3.4.1.3 TST3 — Connection Initialization 


This test will support both the base format and Extended Format safety connection. 
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Requirement A 
Nuniber: Requirement 
FRS280 After the connection is first established, the consuming application shall close base 
format connections if initialization is not completed within 10 seconds. The consuming 
application shall close Extended connections if initialization is not completed within 8.3 
seconds. 
FRS281 For Single-Cast, the flag Init_Complete_Out shall indicate that the first time 


coordination message has been received by the producer and the producer is producing 
data with the time stamp relative to the consumer’s clock. 
FRS282 For Multi-Cast, the flag Init_Complete_Out shall indicate that the first time coordination 


message has been received by the producer for this consumer and the producer has 
received the Ist time correction message based on the time coordination information. 


SRS57 Safety Nodes which reside on DeviceNet shall implement the SafetyOpen and 
SafetyClose services of the Connection Object. 


TST3 The connection establishment test shall confirm that the Consumer will close its 
connection if initialization isn’t completed within the required time. 


Required Initial Conditions: 


1. This test will support both the base format and Extended Format safety connection. 


2. Run SPTE as an originator. 
Test Procedure: 


1. If the DUT Supports Multi-cast consumer, 

Configure the DUT so it originates a multi-cast connection request 
Confirm the service code used 0x54 

Reply appropriate for the connection to be established 
Begin producing data and generate a ping count change. 
Confirm the DUT sends a Time Coordination response 
Continue sending data, but don’t send a Time Correction message. 


90: SON SGN 


If Extended Format is used, confirm that the DUT no longer responds to Ping Count 
changes after 8.3 seconds OR (EPI*Ping_Interval_EPI_Multiplier * 
(Timeout_Multiplier.PI+1)), whichever is less 
9. If base format is used, confirm that the DUT no longer responds to Ping Count changes 
after 10 seconds OR (EPI*Ping_Interval_EPI_Multiplier * (Timeout_Multiplier.PI+1)), 
whichever is less 


0. Confirm the DUT attempts to re-establish the connection. 
1. If the DUT supports Single-cast consumer 


2. Configure the DUT and initiate a type 2 connection to the DUT targeting the Connection 
Object with service code 0x54 


3. Confirm the device accepts the connection 
Complete the SafetyOpen exchange 


5. If Extended Format is used, don’t produce data until after 8.3 seconds OR 
(EPI*Ping_Interval_EPI_Multiplier * (Timeout_Multiplier.PI+1)), whichever is less 


6. If base format is used, don’t produce data until after 10 seconds OR 
(EPI*Ping_Interval_EPI_Multiplier * (Timeout_Multiplier.PI+1)), whichever is less 
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F-3.4.1.4 


17. Send data with ping count changes 

18. Confirm the DUT does not respond with Time Coordination messages. 

19. Close the connection 

20. Confirm the connection must be re-established before communication continues. 
21. If the DUT supports Single-cast producer 


22. Configure the DUT and initiate a type 2 connection to the DUT targeting the Connection 
Object with service code 0x54 


23. Confirm the device accepts the connection 
24. Complete the SafetyOpen exchange 


25. — If Extended Format is used, don’t respond to ping count changes until after 8.3 seconds 
OR (EPI*Ping_Interval_EPI_Multiplier * (Timeout_Multiplier.PI+1)), whichever is less 


26. If base format is used, don’t respond to ping count changes until after 10 seconds OR 
(EPI*Ping_Interval_EPI_Multiplier * (Timeout_Multiplier.PI+1)), whichever is less 


27. Confirm the DUT stops producing data 


28. Close the connection 
29. Confirm the connection must be re-established before communication continues. 


TST4 - Connection Parameters CRC Negative Test 


This test will verify that the target detects errors via the parameters CRC in either the Base 
format or Extended Format SafetyOpens. Since this CRC is software generated, it is easy to 
simulate these errors. 


Requirement 


Number Requirement 


SRS180 A target device that has an existing configuration shall (at a minimum) do the following when 
a type 2a or 2b Safety Open is received. 


Verify the CPCRC over the configuration is correct 
Verify that the TUNID in the SafetyOpen matches the device TUNID 
Verify the Electronic Key matches the device 


If the connection path is to an output resource, verifies that the OUNID in the SafetyOpen 
matches the OUNID for the connection, 


Tf the SCID is non-zero, confirm the SCID matches the device SCID 
verify and validate the connection parameters, 

Validate the application path 

Confirm the safety connection requested is supported 

Safety parameters are within valid ranges 


transition the connection to the established state 


TST4 The Connection Parameter CRC Negative test shall confirm the target DUT will detect 
the case when the connection parameters do not match the CPCRC value 


Required Initial Conditions: 


1. This test will support both Base and EF SafetyOpen Formats for this test 
2. Run SPTE as an originator and Safety I/O connection supported by the DUT 
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F-3.4.1.5 


Test Procedure: 


1. Confirm the connection is established without error 


Close the connection 


Open the same connection, but with a CPCRC that does not match the connection 


parameters 


4. Confirm the target DUT rejects the connection 


TSTS - Type 2 SCID Checking Tests 


This test will support both the base format and Extended Format safety connections. 


Requirement A 
Namiber: Requirement 

FRS163 The SCID = 0 in a Type 2b SafetyOpen shall have special meaning to indicate that the 
SCID shall not be checked by a target before accepting the connection. 

SRS2 Type 2a: When a target receives a Type 2 SafetyOpen accompanied by a non-zero 
Safety Configuration ID (SCID = SCCRC+SCTS), it shall compare it against the SCID 
of the configuration and only accept the connection if they match. 

SRS5S Also, Safety Devices shall NV-store the signature for the configuration (SCID) in the 


device. 


TSTS The Type 2 with matching SCID Test shall confirm that the DUT correctly reacts to 
these under the various SCID conditions. 


Required Initial Conditions: 


1. This test will support both the base format and Extended Format safety connections 


2: Run SPTE as an originator. 


Test Procedure: 


1. Configure the DUT with a representative configuration and SCID to establish initial 
conditions and ownership 


Close all connections 


Issue a SafetyOpen without configuration data and a different Time Stamp in the SCID 
with owner OUNID 


4. Confirm the device rejects the connection 


3: Issue a SafetyOpen without configuration data and a different Time Stamp in the SCID 
with a different OUNID 


Confirm the device rejects the connection 


Issue a SafetyOpen without configuration, but with an incorrect CRC in the SCID with 
owners OUND 


8. Confirm the device rejects the connection 


Issue a SafetyOpen without configuration, but with an incorrect CRC in the SCID with 
different OUND 


10. Confirm the device rejects the connection 
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F-3.4.1.6 


If the connection resource is NOT an output, execute the following 2 steps. 
1. Issue a SafetyOpen with no configuration and an SCID =0 with different OUNID 
2. Confirm the device accepts the connection. 

TST6 - Electronic Key Mismatch test 


These tests will generate requests with incorrect keying information and verify the target rejects 
the connection. This test will support both the base format and the Extended Format safety 
connections. 


Requirement 4 
Namiber Requirement 
FRS342 The Electronic Key shall always be processed by Target devices with integrity (cannot be 
confirmed externally) 
FRS344 The compatibility bit and behavior in the Electronic Key shall be supported as defined by 
safety originators and targets, wildcards (fields set to 0) for individual fields within the 
Electronic Key shall not be supported 


TST6 The Electronic Key Mismatch test shall confirm that when a SafetyOpen is sent with a 
non-matching key is rejected by the target. 


Required Initial Conditions: 


1. This test will support both the base format and the Extended Format safety connections. 
2: Run Test Engine. 


Test Procedure: 


1. Issue a series of SafetyOpens, each with one of the electronic key parameters set to an 
invalid value and the compatibility bit in the Major Rev set to 0 


Di Invalid vendor Id 

3: Invalid Product Type 

4. Invalid Product Code 

5; Invalid Major Rev 

6. Invalid Minor Rev 

és Confirm the SafetyOpen is rejected 

8. Issue a series of SafetyOpens, each with one of the electronic key parameters set to a 
zero value and the compatibility bit in the Major Rev set to 0 

9: Invalid vendor Id 

10. Invalid Product Type 

11. Invalid Product Code 

12. Invalid Major Rev 

13. Invalid Minor Rev 


14. Confirm each SafetyOpen is rejected 


15. Issue a SafetyOpen, with a matching electronic key and compatibility bit in the major 
revision set to 0 (all must match) 


16. Confirm the SafetyOpen is accepted 


-F-15- 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Appendix F: Safety Test Plan 


F-3.4.1.7 TST7 -Target Connection Id Allocation Tests 


This test will support both the base format and the Extended Format safety connections 


Requirement 


Number Requirement 


SRS95 During connection processing of a SafetyOpen DeviceNet safety identifiers shall be 
assigned from the available pool of DeviceNet Group | identifiers 


SRS96 Safety connection originators shall initially ask the target (via SafetyOpen) to allocate one, 
two, or three identifiers according to the rules stated in Table 24. 

(This is accomplished by inserting OxFFFF identifiers in the SafetyOpen request sent to the 
target) 


SRS97 If a safety target cannot or refuses to allocate the identifier(s), the target shall respond to 
the Safety Open request with a 0x01 general error status with extended status 0x031F 
indicating no connection resources are available. 


SRS99 In order to provide consistency among producers and consumers, the following rule shall 
be used when allocating identifiers: The first MSGID to be allocated shall start at the 
highest available value and move downward. 


SRS100 Multi-Cast producers must allocate an identifier from its own pool, i.e. the source MACID 
must be that of the producer. Multi-cast producers shall reject any connection request that 
attempts to assign IDs for its produced data or time correction data 


SRS179 When a safety device closes a connection in which group | IDs were allocated to another 
device, the group 1 ID shall be placed into quarantine for a period equal to the 
(connection_EPI * Ping_Interval_Multiplier) * (Timeout_Multiplier.PI+2). During this 
time, the ID cannot be used or allocated to another device. 


TST7 The Target Connection Id Allocation test shall confirm proper allocation rules are being 
followed. 


Device Capability Requirements: 


To execute this test, it assumes that it is possible to create a sufficient number of connections to 
deplete the available number of Group 1 identifiers. This test therefore requires the device 
supports at least 1 single-cast and 1 multi-cast with at least 8 consumers. If a device does not 
support these capabilities, the quarantine requirement (SRS179) won’t be confirmed. Devices 
which can’t be tested must take responsibility to independently confirm they are quarantining 
identifiers properly. This test will support both the base format and the Extended Format safety 
connections 


Required Initial Conditions: 

1. Run Test Engine. 

Test Procedure: 

1. Commission and Configure the DUT with a representative configuration and SCID to 
establish initial conditions 


2. Issue a SafetyOpen to the DUT for one of each type of safety service the DUT supports. 
All supported services should be tested 

3. When connecting to a Single-cast output, fill in all identifiers with OxFFFF to request 
the Target allocate all the Ids 

4, When connecting to a Multi-cast input, provide an identifier for the tester production and 
fill in OXFFFF for all identifiers the Target will produce on 
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5: Confirm the Ids are allocated from the highest range of Group 1 Ids 


If the device supports more connections, continue to open additional connections until 
the Target has allocated all available Ids. 


Ws Confirm that after the Ids are used up, the DUT responds with an error 0x01 extended 


code 0x031F 

8. Generate a CRC error on one of the single-cast output connections so the target closes 
the connection and puts the group 1 Ids in quarantine. Note the connection Ids that were 
used 

9. During the quarantine period, open another connection (to a different resource if 


possible) and request all the Ids. 
10. Confirm the DUT does not allocate the IDs that should be in quarantine 


TSTS8 - Multi-cast Producer, Consumer Number Allocation 


This test will make sure Multi-cast producers quarantine consumer numbers for the required 
period of time. This test will support both the base format and the Extended Format safety 
connections 


Requirement - 
Number Requirement 
FRS325 The Validator Connection Establishment Engine shall ensure that the Consumer_Open 


resource for any allocated consumer number is set to Closed for a minimum time of 
(Timeout_Multiplier.PI+2) * Ping Interval prior to re-allocating that Consumer number to 
another connection. This is to ensure that any previously established connections have 
timed out prior to allocating the number to a new connection. 


TST8 The Multi-cast Producer Consumer_Number Allocation test shall confirm that the 
producer quarantines consumer numbers properly. 


Required Initial Conditions: 


1. This test will support both the base format and the Extended Format safety connections 
2: Run Test Engine. 
Ss Input: Max_number_of_consumers supported by the device 


Test Procedure: 


ile The test shall establish consumer connection with producer DUT so max consumers 
supported are in use. 

2. The tester will log the consumer numbers allocated to each consumer. 

3: The tester will stop responding to ping requests on 1 consumer (note the consumer #) 

4, The tester will wait until the producer detects the failure and closes the connection. 

35 The tester will attempt to re-establish the connection using another Node Id, but before 
the Timeout_Multiplier.PI+2 ping intervals has gone by. 

6. The tester shall confirm that the producer DUT rejects the connection 
The tester will repeat the connection attempt after the Timeout_Multiplier.PI + 2 Ping 


Intervals has gone by 
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F-3.4.1.10 


TST99 - DeviceNet Base Format Multi-cast Producer Time Correction 
Connections 


When the DeviceNet protocol is used for the multi-cast connection type the time correction 
section is not part of the data message. The data section and time stamp section are transmitted 
on a separate link and the time correction data is transmitted on a separate link. This test 
confirms that the base format Target Multi-cast producer on DeviceNet responds to a 
SafetyOpen with the proper number of connections. 


Requirement 
Requirement 
Number a 
FRS29 For devices on a DeviceNet network, the Multi-cast Time_Correction_Value shall be sent 
to the consumers via a separate mutli-cast link connection. 
FRS92 For DeviceNet Multi-cast connections, a separate message shall be used to communicate 
time correction information form the produce to each multi-cast consumer. 


TST99 The Multi-cast Producer Time Correction Connection test shall confirm that the base 
format multi-cast producer DUT will generate proper connection resources. 


Required Initial Conditions: 
1. Run the SPTE as Client 


Test Procedure: 


1. The SPTE sends a safety open to the DeviceNet Producer DUT 

2: The DUT will receive the safety open. 

3. The test confirms the DUT sends a valid safety open response of the proper type. 

4. The test shall confirm the DUT sets up 3 separate connections. 

5. The DUT will send the 1° data message over the Ist link. The data message is the data 
section and time stamp section. 

6. The test will receive the 1 data message and verify the data message composition and 
Ping Request 
The test will send a valid time coordination message over the 2" link. 

8. The DUT will receive the time coordination message and send a time correction message 
over the 3rd link. 

9. The test will receive the time correction message and verify the data. 


TST120 - DeviceNet Extended Format Multi-cast Producer Time Correction 
Connections and Rollover Seeding 


When the DeviceNet protocol is used for the Extended Format multi-cast connection type the 
time correction section is a special format not part of the data message. The data and time 
stamp are transmitted on a separate link and the time correction data is transmitted on a 
separate link. This test confirms that the Extended Format Target Multi-cast producer on 
DeviceNet responds to a SafetyOpen with the proper number of connections and confirms the 
proper format for the Time Correction message. 
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REELNGETIa Requirement 
Number a 

FRS29 For devices on a DeviceNet network, the Multi-cast Time_Correction_Value shall be 
sent to the consumers via a separate mutli-cast link connection. 

FRS92 For DeviceNet Mult connections, a separate mes: shall be used to communicate 
time correction information form the produce to each multi-cast consumer. 

FRS371 When a connection is established with the Extended format, the EF Time Correction 
format shall be used; otherwise the base format shall be used 

FRS378 The active seeding of the CRC with the rollover count in Extended Format Multi-cast 
messages shall begin immediately on first production. 


TST120 The Extended Format Multi-cast Producer Time Correction Connection test shall 
confirm that the Extended Format multi-cast producer DUT will generate proper connection 
resources with the proper formats on DeviceNet. 


Required Initial Conditions: 
1. Run the SPTE as Client 
Test Procedure: 


1. The SPTE sends a SafetyOpen for a Multi-cast input (DUT produces data) with the 
proper segment type to the DeviceNet Producer DUT 

The DUT will receive the safety open. 

The test confirms the DUT sends a valid safety open response of the proper type. 


The test shall confirm the DUT sets up 3 separate connections. 


un Bs ie che 


The DUT will send the 1“ data message over the Ist link. The data message is the data 
and time stamp section with the initial rollover count included in the CRC seeding. 


6. The test will receive the 1“ data message and verify the data message format, CRC, and 
Ping Request 
The test will send a valid Extended Format time coordination message over the 2" link. 


The DUT will receive the Extended Format time coordination message and send a 
Extended Format time correction message over the 3rd link. 


9. The test will receive the Extended Format time correction message and verify the data. 
Type 2 Connection Generation by Originators 
TST®9 - Positive Type 2 Single-Cast Connections on DeviceNet 


This test is a positive test that confirms that the originator DUT on DeviceNet generates a 
proper SafetyOpen request without configuration data. No configuration functionality is 
confirmed in this test. The test will validate the SafetyOpen packet generated. This test will 
support both the base format and the Extended Format safety connection. 


Requirement Fe 
Naimbae Requirement 

FRS153 All CIP Safety connections shall be established using a Forward_Open with a safety 
network segment (EtherNevV/IP, SERCOS III) or a SafetyOpen (DeviceNet) 

FRS166 To establish ownership of the configuration (and the connection in outputs), in targets 
the OUNID of the originating device shall be passed to the target in the SafetyOpen 
service. 

—F-19- 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Appendix F: Safety Test Plan 


Requirement f 
Nanaber! Requirement 

FRS170 DeviceNet originators shall use the Connection Object’s Safety Open request for local 
targets 

SRS57 Safety Nodes which reside on DeviceNet shall implement the SafetyOpen and 
SafetyClose services of the Connection Object. 

SRS96 Safety connection originators shall initially ask the target (via SafetyOpen) to allocate 
one, two, or three identifiers. 
(This is accomplished by inserting OxFFFFFFFF identifiers in the SafetyOpen request 
sent to the target) 

FRS373 All Extended Format safety connections shall be established using the Extended format 
safety network segment in a Forward_Open (EtherNet/IP, SERCOS III) or a SafetyOpen 
(DeviceNet). 

FRS379 When Extended Format single-cast connections are originated by the producer (i.e. 


outputs), the target consumer shall provide initialization values in the SafetyOpen 
Response. 


TST9 The Positive Type 2 Connection Generation Test shall confirm that the originator DUT 
generates a proper DeviceNet Single-Cast SafetyOpen message for both the EF and base 


format . 


Required Initial Conditions: 


I, Configure the DeviceNet originator DUT with a single-cast I/O connection and 
representative configuration. This test will support both the base format and the 
Extended Format safety connection 


2. Run SPTE as server. Input the connection parameters configured in the originator 


Test Procedure: 


Confirm the DUT opens a Class 3 connection 


The tester accepts this connection 


1 
2 
3: Confirm the DUT issues the SafetyOpen by requesting the target provide all the Ids 
4 


Test wi 
0x54 


Test wi 
Test wi 


Test wi 


SOF SON) 


Test wi 


9. Test wi 
10. Test wi 
11. Test wi 
12. Test wi 


originator 


con 


con 


irm a SafetyOpen is sent over the class 3 connection with service code 


irm the service message is routed to the connection object 


inspect the SafetyOpen and confirm the parameters are correct 


con 


firm the CPCRC is correct 


confirm the safety segment type is correct for the format configured in the 


con 


irm the OUNID matches the originator 


‘irm the TUNID matches the configured value 


confirm the Electronic Key matches the configured value 


confirm the Connection Parameters match the configured values 


13. Test will confirm the Time Correction parameters are null values 


14. If the segment type is the Extended Format, the test will confirm the Initial Time Stamp 


15. Test wi 


and Initial Rollover value are set to OxFFFF 


reply with a success SafetyOpen Response of the proper type and values 
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16. Test will confirm the DUT accepts the response and the safety connection is established 


F-3.4.2.2 TST118 - Positive Type 2 Single-Cast Connections on EtherNet/IP 


This test is a positive test that confirms that the originator DUT on EtherNet/IP generates a 
proper Safety Forward Open request without configuration data. No configuration 
functionality is confirmed in this test. The test will validate the Forward Open packet 
generated. This test will support both the base format and the Extended Format safety 


connection. 
Requirement 7 
Namiben Requirement 

FRS153 All CIP Safety connections shall be established using a Forward_Open with a safety 
network segment (EtherNet/IP, SERCOS III) or a SafetyOpen (DeviceNet) 

FRS166 To establish ownership of the configuration (and the connection in outputs), in targets 
the OUNID of the originating device shall be passed to the target in the SafetyOpen 
service. 

FRS373 All Extended Format safety connections shall be established using the Extended format 
safety network segment in a Forward_Open (EtherNet/IP, SERCOS IID) or a SafetyOpen 
(DeviceNet). 

FRS379 When Extended Format single-cast connections are originated by the producer (i.e. 
outputs), the target consumer shall provide initialization values in the SafetyOpen 
Response. 


TST118 The Positive Type 2 Connection Generation Test shall confirm that the originator 
DUT generates a proper EtherNet/IP Single-Cast SafetyOpen message for both the EF and base 
format 


Required Initial Conditions: 


1. Configure the EtherNet/IP originator DUT with a single-cast I/O connection and 
representative configuration. This test will support both the base format and the 
Extended Format safety connection 


2: Run SPTE as server. Input the connection parameters configured in the originator 
Test Procedure: 


iy Confirm the DUT issues the Forward Open with the proper safety segment 


2. Test will confirm a Forward Open with service code 0x54 

3. Test will confirm the service message is routed to the connection manager object 

4. Test will inspect the Forward Open and confirm the parameters are correct 

5. Test will confirm the CPCRC is correct 

6. Test will confirm the safety segment type is correct for the format configured in the 
originator 

7. Test will confirm the OUNID matches the originator 

8. Test will confirm the TUNID matches the configured value 

9. Test will confirm the Electronic Key matches the configured value 

10. Test will confirm the Connection Parameters match the configured values 

11. Test will confirm the Time Correction parameters are default values 
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2. If the segment type is the Extended Format, the test will confirm the Initial Time Stamp 
and Initial Rollover value are set to OxFFFF 


Test will reply with a success SafetyOpen Response of the proper type and values 


4. Test will confirm the DUT accepts the response and the safety connection is established 


TST10 - Positive Type 2 Multi-cast Connections on DeviceNet 


[his test is a positive test that confirms that the originator DUT on DeviceNet generates a 
proper Multi-cast SafetyOpen request without configuration data. No configuration 
functionality is confirmed in this test. The test will validate the SafetyOpen packet generated. 
This test will support both the base format and the Extended Format safety connection. 


Requirement i 
Nanibed Requirement 

FRS29 For devices on a DeviceNet network, the Multi-cast Time_Correction_Value shall be 
sent to the consumers via a separate multi-cast transport connection. 

FRS153 All CIP Safety connections shall be established using a Forward_Open with a safety 
network segment (EtherNet/IP, SERCOS III) or a SafetyOpen (DeviceNet) 

FRS170 DeviceNet originators shall use the Connection Object’s Safety Open request for local 
targets 

FRS373 All Extended Format safety connections shall be established using the Extended format 
safety network segment in a Forward_Open (EtherNet/IP, SERCOS IID) or a SafetyOpen 
(DeviceNet). 

FRS377 When Extended Format multi-cast connections are originated by the consumer (i.e. 
multi-cast inputs); the target producer shall provide initialization values in the 
SafetyOpen Response. 

SRSS7 Safety Nodes which reside on DeviceNet shall implement the SafetyOpen and 
SafetyClose services of the Connection Object. 

SRS95 During connection processing of a SafetyOpen DeviceNet safety identifiers shall be 
assigned from the available pool of DeviceNet Group | identifiers 

SRS96 Safety connection originators shall initially ask the target (via SafetyOpen) to allocate 
one, two, or three identifiers. 
(This is accomplished by inserting OXFFFFFFFF identifiers in the SafetyOpen request 
sent to the target) 

SRS99 In order to provide consistency among producers and consumers, the following rule 
shall be used when allocating identifiers: The first MSGID to be allocated shall start at 
the highest available value and move downward. 


TST10 The Positive Type 2 Multi-cast Connection Generation on DeviceNet test shall confirm 
the originator DUT will generate a proper connection request for both base and Extended 
Formats. 


Required Initial Conditions: 


1. Configure the DeviceNet originator DUT with a Multi-cast consumer I/O connection and 
representative configuration for either the base format or Extended Format 


2. Run SPTE as server. Input the connection parameters configured in the originator 


Test Procedure: 


1. Confirm the DUT opens a Class 3 connection 
2 The tester accepts this connection 
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3. Confirm the DUT issues the SafetyOpen with proper safety segment and by providing 
Ids for its producing connections, but requests Ids for the targets producing connections 


4. Confirm that the allocated Ids are from the high-end of the group | range 


5. Test will con 
0x54 


Test will con: 


een HN 


Test will con 
originator 


Test will con: 


Test will con 


wp w& 


irm a SafetyOpen is sent over the class 3 connection with service code 


Test will confirm the service message is routed to the connection object 


Test will inspect the SafetyOpen and confirm the parameters are correct 


irm the CPCRC is correct 


irm the safety segment type is correct for the format configured in the 


0. Test will confirm the OUNID matches the originator 


firm the TUNID matches the configured value 


12. Test will confirm the Electronic Key matches the configured value 


irm the Connection Parameters match the configured values 


Test will confirm that the Time Correction connection is included 


If the segment type is the Extended Format, the test will confirm the Initial Time Stamp 
and Initial Rollover value are set to OxFFFF 


Test will reply with a success SafetyOpen Response of the proper type and values 
Test will confirm the DUT accepts the response and the safety connection is established 
TST119 - Positive Type 2 Multi-cast Connections on EtherNet/IP 


[his test is a positive test that confirms that the originator DUT on EtherNet /IP generates a 


proper Multi-cast SafetyOpen request without configuration data. No configuration 
functionality is confirmed in this test. The test will validate the Safety Forward Open packet 
generated. This test will support both the base format and the Extended Format safety 


connection 
Requirement i 
NABER Requirement 

FRS30 For devices on a non-DeviceNet network, the data and Time_Correction_Value shall be 
concatenated and sent to the consumers via a single multi-cast transport connection. 

FRS153 All CIP Safety connections shall be established using a Forward_Open with a safety 
network segment (EtherNet/IP, SERCOS III) or a SafetyOpen (DeviceNet) 

FRS373 All Extended Format safety connections shall be established using the Extended format 
safety network segment in a Forward_Open (EtherNet/IP, SERCOS III) or a SafetyOpen 
(DeviceNet). 

FRS377 When Extended Format multi-cast connections are originated by the consumer (i.e. 


multi-cast inputs); the target producer shall provide initialization values in the 
SafetyOpen Response. 


TST119 The Positive Type 2 Multi-cast Connection Generation on EtherNet/IP test shall 
confirm the originator DUT will generate a proper connection request for both base and 


Extended Formats. 


Required Initial Conditions: 


1. Configure the EtherNet/IP originator DUT with a Multi-cast consumer I/O connection 
and representative configuration for either the base format or Extended Format 
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2: Run SPTE as server. Input the connection parameters configured in the originator 
Test Procedure: 


Confirm the DUT issues the SafetyOpen with the proper safety segment 

Test will confirm a SafetyOpen is sent with service code 0x54 

Test will confirm the service message is routed to the connection manager object 
Test will inspect the SafetyOpen and confirm the parameters are correct 

Test will confirm the CPCRC is correct 


Oy. On BA On Boies 


Test will confirm the safety segment type is correct for the format configured in the 
originator 


a 


Test will confirm the OUNID matches the originator 

Test will confirm the TUNID matches the configured value 

Test will confirm the Electronic Key matches the configured value 

0. — Test will confirm the Connection Parameters match the configured values 
Test will confirm that the Time Correction parameters are the default values 


2. If the segment type is the Extended Format, the test will confirm the Initial Time Stamp 
and Initial Rollover value are set to OXFFFF 


3. Test will reply with a success SafetyOpen Response of the proper type and values 


4. — Test will confirm the DUT accepts the response and the safety connection is established 


F-3.4.2.5 TST114- Positive Extended Format Type 2 Single-Cast Connection 
Origination 


This test is a positive test that confirms that the originator DUT generates a proper SafetyOpen 


request with the correct segment type without configuration data. No configuration 
‘unctionality is confirmed in this test. The test will validate the SafetyOpen packet generated. 
This procedure is written so that it can be applied to either EtherNet/IP or DeviceNet. 
Requirement i 
Namber Requirement 

FRS153 All CIP Safety connections shall be established using a Forward_Open with a safety 
network segment (EtherNet/IP, SERCOS III) or a SafetyOpen (DeviceNet) 

FRS166 To establish ownership of the configuration (and the connection in outputs), in targets 
the OUNID of the originating device shall be passed to the target in the SafetyOpen 
service. 

FRS373 All Extended Format safety connections shall be established using the Extended format 
safety network segment in a Forward_Open (EtherNet/IP, SERCOS IID) or a SafetyOpen 
(DeviceNet). 


TST114 The Positive Extended Format Type 2 Connection Generation Test shall confirm that 
the originator DUT generates a proper Extended Format Single-Cast SafetyOpen message 


Required Initial Conditions: 


1. Configure the originator DUT with a Extended Format single-cast I/O connection and 
representative configuration 
2: Run SPTE as server. Input the connection parameters configured in the originator 
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Test Procedure: 


1. Confirm the DUT sends the SafetyOpen with the Extended Format 


The tester accepts this connection 


i? 


Test will confirm the service message is routed to the connection manager object if the 
DUT is on EtherNet/IP or over an explicit connection to the connection object if the 
DUT is on DeviceNet 


4 Test will inspect the SafetyOpen and confirm the parameters are correct 
5 Test will confirm the CPCRC is correct 

6. Test will confirm the safety segment is present 

7 Test will confirm the OUNID matches the originator 

8 Test will confirm the TUNID matches the configured value 

9: Test will confirm the Electronic Key matches the configured value 

10. Test will confirm the Connection Parameters match the configured values 
11. Test will confirm the Time Correction parameters are null values 


12. Test will confirm the Initial Time Stamp and Initial Rollover Value set to values other 
than OxFFFF 


13. Test will reply with a success standard SafetyOpen Response 


14. Test will confirm the DUT accepts the response and the safety connection is established 


F-3.4.2.6 TST115- Positive Extended Format Type 2 Multi-Cast Connection Origination 


This test is a positive test that confirms that the originator DUT generates a proper Multi-cast 
SafetyOpen request with the correct segment type without configuration data. No 
configuration functionality is confirmed in this test. The test will validate the SafetyOpen 
packet generated. This procedure is written so that it can be applied to either EtherNet/IP or 


DeviceNet. 
Requirement 3 
amber Requirement 

FRS153 All CIP Safety connections shall be established using a Forward_Open with a safety 
network segment (EtherNet/IP, SERCOS III) or a SafetyOpen (DeviceNet) 

FRS166 To establish ownership of the configuration (and the connection in outputs), in targets 
the OUNID of the originating device shall be passed to the target in the SafetyOpen 
service. 

FRS373 All Extended Format safety connections shall be established using the Extended format 
safety network segment in a Forward_Open (EtherNet/IP, SERCOS III) or a SafetyOpen 
(DeviceNet). 


TST115 The Positive Extended Format Type 2 Multi-cast Connection Generation Test shall 
confirm that the originator DUT generates a proper Extended Format Multi-Cast SafetyOpen 
message and accepts the Extended Format response 


Required Initial Conditions: 


1. Configure the originator DUT with a Extended Format Multi-cast I/O connection and 
representative configuration 
2. Run SPTE as server. Input the connection parameters configured in the originator 
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F-3.4.3 
F-3.4.3.1 


Test Procedure: 


1. Confirm the DUT sends the SafetyOpen with the Extended Format 
The tester accepts this connection 


oe CD 


Test will confirm the service message is routed to the connection manager object if the 
DUT is on EtherNet/IP or over an explicit connection to the connection object if the 
DUT is on DeviceNet 


Test will inspect the SafetyOpen and confirm the parameters are correct 
Test will confirm the CPCRC is correct 

Test will confirm the safety segment is present 

Test will confirm the OUNID matches the originator 


Test will confirm the TUNID matches the configured value 


Co PN nAM SP 


Test will confirm the Electronic Key matches the configured value 
10. Test will confirm the Connection Parameters match the configured values 
11. Test will confirm the Time Correction parameters are null values 


12. Test will confirm the Initial Time Stamp and Initial Rollover Value set to values of 
OxFFFF 


13. Test will reply with a success Extended Format SafetyOpen Response 


14. Test will confirm the DUT accepts the response and the safety connection is established 


TST100 Electronic Key Generation Test 


Requirement ; 
Number Requirement 
FRS341 The Electronic Key segment shall be present in all SafetyOpen and Safety Forward Open 
service requests. 


TST100 The Electronic Key Generation Tests shall confirm that originators provide a valid 
Electronic Key segment with every SafetyOpen or Safety Forward Open. 


Required Initial Conditions: 


Li, This test will support both the base and Extended Format type SafetyOpen or Safety 
Forward Open and will operate over DeviceNet or EtherNet/IP 


2. Commission and Configure the DUT with a representative configuration to establish 
initial conditions. Configure Single cast targets and multi-cast producing targets. 
3. Run SPTE as server. Input the connection parameters configured in the originator 


Test Procedure: 


1. Confirm the originator provides any electronic key segment as part of the SafetyOpen or 
Safety Forward Open 
SafetyClose Tests 
TST101 SafetyClose Processing by Targets 
Requirement i 
Number Requirement 
FRS337 Targets receiving the SafetyClose service request shall close the connection who’s 
Originator Vendor ID, Connection Serial Number, and Originator Serial Number 
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Requirement i 
Naber! Requirement 
parameters match. Additional information provided by this service (ie, Connection Path) 
shall be ignored by the target. 
FRS335 The SafetyClose request shall cause all resources in all nodes participating in the 
connection to be deallocated, including connection IDs, bandwidth, and internal memory 
buffers. 


TST101 The SafetyClose processing by Targets test shall verify that targets accept the message 
and properly close the associated connection. 


Required Initial Conditions: 


hy Commission and Configure the DUT with a representative configuration to establish 
initial conditions. 


2: This test will support either base format or Extended Format connections 
Test Procedure: 


Establish connection of the DUT. 


Complete all Time Coordination steps to completely establish the connection 


Coen ea 


Send a Safety Close with the Originator Vendor Id, Connection Serial Number, and 
Originator Serial Number used in the initial SafetyOpen 


Confirm the device sends a success response 
Establish connection of the DUT. 
Complete all Time Coordination steps to completely establish the connection 


Se 


Send a Safety Close with different Connection Serial Number used in the initial 
SafetyOpen 


8. Confirm the device sends an error response 
Common Run-Time Tests 


This section shall define a core series of tests that will be referenced in the test procedures of 
other black box tests. These tests form a core library of scripts that are common to all run-time 
messaging. 


After a connection has been established, the positive test engines will maintain connections if 
the data messages are generated correctly and transmitted/received within the timing 
parameters. Safety devices can be producers, consumers, or both. The safety device 
connections can be single-cast or multi-cast. 


The common positive-behavior tests are organized by functionality where applicable. 


A producer generates and transmits data messages and receives time coordination 
messages. 


a. multi-cast connection 
b. — single-cast connection 


2: A consumer receives data messages and generates and transmits time coordination 
messages. 


a. multi-cast connection 
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F-3.5.1.1 


b.  single-cast connection 


Some requirements are independent of the connection type or device type. Data message size, 
safety CRC usage, etc. These requirements are organized as separate tests. 


Positive Producer Tests 


When testing a DUT producer the tester will be the consumer. The tester will generate time 
coordination messages, verify any data message received. These tests will be used by both the 
originator and target positive test engines. 


TST13 - Producer CRC & PID/CID Test 


The Producer ID (PID) is the initial seed value for the safety CRC’s of all messages from the 
data producer of a connection. The Consumer ID (CID) is the initial seed value for the safety 
CRC’s of all messages from the consumer of a connection. Every message that is transmitted or 
received will have the safety CRC verified. 


Requirement i 
Nuniber Requirement 

FRS32 All safety messages and safety response messages shall be encoded with the safety 
CRC’s defined in Appendix E 

FRS155 The Producer Identifier (PID) shall be used as an initial seed value in the CRCs in the 
runtime protocol. 

FRS330 The Consumer Identifier (CID) shall be used as an initial seed value in the CRC in the 
Time Coordination message. 

FRS331 The Producer shall obtain the Consumer Identifier from either the SafetyOpen or the 
SafetyOpen Response (depending upon originator) and use the value as an initial seed in 
runtime checking the safety CRCs 

SRS152 During connection establishment the producing and consuming nodes shall exchange 
their respective PID/CID information (Vendor ID + Device Serial Number + Connection 
Serial Number). The originator sends its ID in the SafetyOpen request, and the target 
returns its ID as part of the SafetyOpen Success response. 

SRS178 The PID shall be used to seed Data production CRCs and Time Correction CRC, and the 
CID shall be used to seed the Time Coordination CRC. 


TST13 The Producer CRC & PID/CID Run-Time Test shall be a positive test to confirm that 
the Producer DUT is both creating proper safety CRCs with the PID and interpreting valid 
safety CRCs with the CID. 


Required Initial Conditions: 


1. This test will apply to both base and Extended Format connections 

2. A connection must exist between the test and the Producer DUT. The connection process 
has previously exchanged the PID and CID between the originator and the target. 

Test Procedure: 

i All messages received from the DUT will have the safety CRC’s recalculated with the 
PID and the received data. 
The safety CRC’s will be verified to be equal. 


All messages transmitted to the DUT will have the safety CRC’s calculated with the CID 
by the test. 
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F-3.5.1.2 


F-3.5.1.2.1 


This test will not generate CRC error conditions or confirm such detection at the DUT. While 
this test is running, no error or faults should be generated by the DUT. 


Producer Data Message Generation 


The tests in this section will verify the requirements that the data section of the data message is 
generated correctly. The data section is common to devices and connection types. These tests 
will use other tests that check the CRC’s are calculated using the PID and mode byte. Test 11 
through 13 will be executed on all transmitted DUT data messages. 


TST14 - Base Format Producer - 1 to 2 Bytes Data 


When the base format data size is 1 or 2 bytes the data section consists of data, mode byte, data 
CRC and complemented data CRC. 


Requirement a 
Nomben Requirement 
FRS38 The | or 2 Byte Data section for the base format shall consist of the actual data byte or 
bytes, the mode byte, the actual CRC, and the complement CRC. 
FRS39 The Base format | or 2 Byte Actual Data CRC calculation shall include: 


Producer Identifier (PID) (by CRC-S1) 
The (Mode Byte) AND (OxE0) (by CRC-S1) 
Actual Data byte(s) (by CRC-S1) 


FRS40 The Base Format | or 2 Byte Complement Data CRC calculation shall include: 
Producer Identifier (PID) (by CRC-S1) 

The (Mode Byte XOR OxFF) AND (OxE0) (by CRC-S2) 

Actual Data bytes XOR OxFF (by CRC-S2) 


TST14 The Base format Producer Packet Generation - 1 to 2 Bytes Data - Positive test shall 
confirm that the producer is generating the 1-2 byte data packet correctly. 


Required Initial Conditions: 


1. A safety I/O connection must exist between the test and the Producer DUT. The 
connection process has previously exchanged the PID and CID between the originator 
and the target. 


2. A data message is received by the tester. 
Test Procedure: 
The data section of the data message is verified to be built correctly. 


Run TST13, Producer CRC & PID/CID Run-Time Test 


The test complements the received data and recalculates the complemented data CRC. 
The calculated complemented data CRC should be equal to the received complemented 
data CRC. 
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F-3.5.1.2.2. TST109 - Extended Producer - 1 or 2 Bytes Data 


When the Extended format data size is 1 or 2 bytes the data section consists of data, mode byte, 
Time Stamp and data CRC. 


Requirement = 
NunBSr Requirement 
FRS365 The 1 or 2 Byte Data section for the Extended format shall consist of the actual data byte 
or bytes, the mode byte, the time stamp, and CRC-SS calculated over the entire packet. 
FRS366 The Extended 1 or 2 Byte Data CRC calculation shall use CRC-SS and include: 


Producer Identifier (PID) 
16-bit Rollover count 
Mode Byte & 0xEO 
Actual Data byte(s) 
Time Stamp 


TST109 The Extended format Producer Packet Generation - 1 to 2 Bytes Data - Positive test 
shall confirm that the producer is generating the 1-2 byte data packet correctly. 


Required Initial Conditions: 


1. An EF safety I/O connection must exist between the test and the Producer DUT. The 
connection process has previously exchanged the PID, CID and roll-over counts between 
the originator and the target. 


2. A data message is received by the tester. 

Test Procedure: 

1. The data section of the data message is verified to be built correctly. 

2. Run TST13, Producer CRC & PID/CID Run-Time Test 

3. The test calculates the data CRC to include all the components identified in FRS366. 
F-3.5.1.2.3. TST15 - Base Format Producer - 3 to 250 Bytes Data 


When the data size is 3 to 250 bytes the data section consist of data, mode byte, data CRC, 
complemented data and complemented data CRC. 


Requirement 


Naninee Requirement 
FRS41 The Base format 3 to 250 Byte Data section shall consist of the actual data bytes, the mode 
byte, the actual CRC, the complement data bytes, and the complement CRC. 
FRS42 The Base format 3-to250 Byte Actual Data CRC calculation shall include: Producer 


Identifier (PID) (by CRC-S3) The (Mode Byte) AND (OxE0) (by CRC-S3) Actual Data 
byte(s) (by CRC-S3) 


FRS43 The Base format 3 to 250 Byte Complement Data CRC calculation shall include: 
Producer Identifier (PID) (by CRC-S3) 

The (Mode Byte XOR OxFF) AND (0xE0) (by CRC-S3) 

Complemented Data bytes (by CRC-S3) 


TST15 The Base Format Producer Packet Generation — 3 to 250 Byte Data — Positive test shall 
confirm that the producer is generating the 3 to 250 byte data packets correctly. 
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Required Initial Conditions: 


1. A safety I/O connection must exist between the test and the Producer DUT. The 
connection process has previously exchanged the PID and CID between the originator 
and the target. 


2 A data message is received by the tester. 
Test Procedure: 


1. The data section of the data message is verified to be built correctly. 
2. Run TST13, Producer CRC & PID/CID Run-Time Test 
3 


The test complements the received data and compares the received complemented data to 
the test complemented data. The data comparisons should pass. 


4. The test calculates the complemented data CRC using the received complemented data. 
The calculated complemented data CRC should be equal to the received complemented 
data CRC. 


F-3.5.1.2.4 TST110- Extended Format Producer - 3 to 250 Bytes Data 


This test is a positive test to confirm proper operation of a Extended Format producer DUT for 
data sizes greater than 2 bytes. 


Requirement F 
NUnIBer Requirement 
FRS367 The Extended 3 to 250 Byte Data section shall consist of the actual data bytes, the mode 
byte, CRC-S3, the complement data bytes, the time stamp and CRC-S5 
FRS368 The Extended format 3-to250 Byte Actual Data CRC calculation shall include: 


Producer Identifier (PID) (by CRC-S3) 
Rollover Count (by CRC-S3) 

The (Mode Byte) AND (OxE0) (by CRC-S3) 
Actual Data byte(s) (by CRC-S3) 


FRS369 The Extended format 3-to250 Byte Complement Data CRC calculation shall include: 
Producer Identifier (PID) (by CRC-S5) 

Rollover Count (by CRC-S5) 

Mode Byte AND 0x1F (by CRC-S5) 

Complemented Data bytes (by CRC-S5) 

Time Stamp (by CRC-S5) 


TST110 The Extended Format Producer Packet Generation — 3 to 250 Byte Data — Positive test 
shall confirm that the producer is generating the 3 to 250 byte data packets correctly 


Required Initial Conditions: 


1. An Extended Format safety I/O connection must exist between the test and the Producer 
DUT. The connection process has previously exchanged the PID, CID, and Roll-over 
count between the originator and the target. 


2. A data message is received by the tester. 
Test Procedure: 


The data section of the data message is verified to be built correctly. 
Run TST13, Producer CRC & PID/CID Run-Time Test 


The test complements the received data and compares the received complemented data to 
the test complemented data. The data comparisons should pass. 
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F-3.5.1.3 


F-3.5.1.4 


4. The test calculates the actual data CRC using the received data, PID and rollover count. 
The CRC should match the received value 
5. The test calculates the complemented data CRC using the PID, rollover count, 
complemented data and Time Stamp,. The complement CRC should match the values 
sent. 
TST16 - Producer Packet Generation Mode Byte 
Requirement a 
‘Nuuuber Requirement 
FRS126 The TBD_Bit Shall be set to 0 by the Safety Validator 
FRS183 The N_Run_Idle complement bit shall always be the complement of the Run_Idle bit 
FRS191 The N_TBD_Bit complement bit shall always be the complement of the TBD_Bit 


TST16 The Producer Packet Generation Mode Byte — Positive Test shall confirm that the 
producer is generating the Mode byte correctly. 

Required Initial Conditions: 

1. This test will function for both base format and Extended Format connections 

2. A safety I/O connection must exist between the test and the Producer DUT. 

3 A data message is received by the tester. 


Test Procedure: 


The TBD_bit is verified to be set to 0. 
The N_TBD_bit is verified to be set to 1. 
The complement of Run_Idle bit is compared to the received N_Run_Idle bit. The values 
should be equal. 
TST17 - Base Format Producer Packet Time Stamp CRC 


This test will verify the requirements that the time stamp section of the data message is 
generated correctly. The time stamp section is common to devices and connection types. 


Requirement Rf 
Nahar Requirement 
FRS45 The Base format Time Stamp CRC calculation shall include: Producer Identifier byte 
(PID) (by CRC-S1) The (Mode Byte) AND (0x1F) (by CRC-S1) Time Stamp byte(s) 
(by CRC-S1) 


TST17 The Base Format Producer Packet Time CRC Positive test shall confirm that the 
producer is generating the Time Stamp CRC correctly. 


Required Initial Conditions: 


1. A safety I/O connection must exist between the test and the Producer DUT. The 
connection process has previously exchanged the PID and CID between the originator 
and the target. 


2. A data message is received by the test. 
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F-3.5.1.5 


Test Procedure: 


1. The time stamp section of the data message is verified to be built correctly. 


2. The test calculates the time stamp CRC using the received time stamp value. The 
calculated time stamp CRC should be equal to the received time stamp CRC 


TST18 - Producer Time Correction CRC 


The Time Correction section consists of the Mcast_Byte, time correction value, Mcast_Byte_2, 
and CRC. This positive multi-cast producer test will test both EF and base format time 
correction packets. This test will also verify the Time Correction packet is concatenated to the 
data packet when the connection is on EtherNet/IP. 


Requirement a 
Nanbee Requirement 

FRS30 For devices on a non-DeviceNet network, the data and Time_Correction_Value shall be 
concatenated and sent to the consumers via a single multi-cast transport connection. 

FRS68 The Time Correction CRC calculation shall include: Producer Identifier (PID) (by CRC- 
S3) Mcast_Byte (by CRC-S3) Time_Correction_Value (by CRC-S3) 

FRS69 MCast_Byte_2 of the Time Correction message shall not be included in the Safety CRC 

FRS371 When a connection is established with the Extended format, the EF Time Correction 
format shall be used; otherwise the base format shall be used 


TST18 The Producer Time Correction CRC Positive Test shall confirm that the producer is 
generating the Time Correction message correctly. 


Required Initial Conditions: 
1. This test will function for both the Extended Format and the base format 
Test Procedure: 


1. Establish a safety I/O connection of either the EF or Base format with the Producer 
DUT. The connection will exchange the PID and if necessary the rollover count 
between the originator and the target. 


25 If the connection in on EtherNet/IP, verify the Time Correction message is concatenated 
to the data packet with a “NULL” Time Correction packet. 

3: At the first Ping Request, send a Time Coordination response of the proper format. 

4, Tf the connection is on EtherNet/IP, verify a valid, non-NULL Time Correction message 
with the proper consumer number has been concatenated to the produced data packet. 

5. The test calculates the Time Correction CRC using the PID parameters received during 
connection establishment. 

6. The calculated time correction CRC should be equal to the received time correction 
CRC. 

the Tf the base format is being used, the test calculates the time correction CRC with the 


Mcast_Byte_2 included. The calculated time correction CRC with the Mcast_Byte_2 
included should not be equal to the received time correction CRC. 
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F-3.5.1.6 TST19 - Producer Time Correction Mcast Byte & Mcast Byte 2 


The MCast_Byte and MCast_Byte_2 fixed parameters are tested. The Parity_Even bit (bit7) 
forms even parity on bits 0-6. The time correction reserved bits are set to 0. The Mcast_Byte_2 
is derived from the Mcast_Byte with fixed rules. 


Requirement 5 
Nambier Requirement 

FRS62 Parity_Even in the Time Correction message shall be the even parity of bits 0 through 6 
of the Message 

FRS66 The following rule shall be used for the calculation of the parity bit in the Time 
Correction message: Bit 7 of the MCast _Byte form even parity on the MCast _Byte. 

FRS67 The following rule shall be used for setting of the bits in Mcast_Byte_2 in the Time 
Correction message: MCast_Byte_2 = ((MCast_Byte XOR OxFF)AND 
0x55)OR(MCast_Byte AND OxAA) 

FRS215 The Time Correction Reserved bits shall be set to 0 by the producer 


TST19 The Base format Producer Time Correction Mcast_Byte & Mcast_Byte_2 test shall 
confirm that the producer is setting the parity, Mcast and reserved bits correctly in the Time 
Correction Message. 


Required Initial Conditions: 


1. A safety I/O connection must exist between the test and the Producer DUT. The 
connection process has previously exchanged the PID and CID between the originator 
and the target. 


2: A Time Correction message has been received by the test 
Test Procedure: 


Bit 6 of the Mcast_Byte is verified to be 0. 

Bit 6 of the Mcast_Byte_2 is verified to be 1. 

The test calculates the parity for bits 0-7 of the Mcast_Byte. 
The parity calculation should be equal to 0. 

The received Mcast_Byte is used to generate the Mcast_Byte_2. 


Do ie Bh GP 


The generated Mcast_Byte_2 should be equal to the received Mcast_Byte_2. 
F-3.5.1.7 TST111 - Extended Format Producer Time Correction Mcast Byte 


The MCast_Byte parameter is tested in the Extended Format Time Correction Message. The 
Parity_Even bit (bit7) forms even parity on bits 0-6. The time correction reserved bits are set to 


0. 
Requirement A 
NGBES: Requirement 

FRS62 Parity_Even in the Time Correction message shall be the even parity of bits 0 through 6 
of the Message 

FRS66 The following rule shall be used for the calculation of the parity bit in the Time 
Correction message: Bit 7 of the MCast _Byte form even parity on the MCast _Byte. 

FRS215 The Time Correction Reserved bits shall be set to 0 by the producer 

FRS371 When a connection is established with the Extended format, the EF Time Correction 
format shall be used; otherwise the base format shall be used 
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TST111 The Extended Format Producer Time Correction Mcast_Byte test shall confirm that 
the producer is setting the parity, Mcast and reserved bits correctly in the Time Correction 
Message. 


Required Initial Conditions: 


1. An EF safety I/O connection must exist between the test and the Producer DUT. The 
connection process has previously exchanged the PID and CID between the originator 
and the target. 


2h A Time Correction message has been received by the test 
Test Procedure: 


ie Bit 6 of the Mcast_Byte is verified to be 0. 
2: The test calculates the parity for bits 0-7 of the Mcast_Byte. 
3. The parity calculation should be equal to 0. 


TST20 - Base Format Producer Single-Cast 


Requirement fi 
Niuiber Requirement 

FRS16 For single-cast safety connections, the Single-cast Safety ValidatorClient shall produce 
safety data to the Single-cast Safety ValidatorServer as defined by the Expected Packet 
Interval (EPI) rate. 

FRS18 The Single-cast safety data producer shall use the time value returned in the ping 
response (Time Coordination message) to adjust the time stamp sent the Single-cast 
produced data. 

FRS89 At each single-cast producer ping interval, the ping count shall be incremented in the next 
available safety message header. 

FRS90 The single-cast producer ping interval shall be a multiple of the EPI; ping requests shall 
be made at rates based on the Ping_Interval_EPI_Mulitplier 

FRS241 If the connection type is single-cast, the Max_Consumer_Number shall be equal to 1. 

FRS281 For Single-Cast, the flag Init_Complete_Out shall indicate that the first time coordination 
message has been received by the producer and the producer is producing data with the 
time stamp relative to the consumer’s clock. 

FRS283 For Single-Cast, the Data_Time_Stamp value shall be set to 0 by the producer until the 
first time coordination section is received. 


TST20 The Base format Single-Cast Data Production test shall establish a single-cast 
connection to the producing DUT and confirm the data is produced properly 


Required Initial Conditions: 


1. An base format single-cast connection must exist between the test and the Producer 
DUT. The connection process has previously exchanged the PID and CID between the 
originator and the target. 


2. The 1st single-cast message has been received by the test 

Test Procedure: 

1. The test verifies that the time value is 0 in the initial data message. 
2. The test verifies that the Data Time Stamp is = 0 


3. The initial ping count value is saved. 
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4. The test verifies that the max consumer number = | 

5: The test responds with a valid time coordination message. 

6. The 2™ data message is received. 

7. The test verifies that the data message was received at the EPI rate. 

8. The test verifies that the time value is a value that is relative to the time coordination 
message’s consumer time value. 

9. As additional data messages are received, steps 7, 8, and 9 are repeated for each 
message. 

10. The test will keep a count of the data messages received. The ping count value is 


monitored and when a change is detected the test will compare the message count to the 
ping count interval value. This test will be executed for a period of time. 


TST121 - Extended Format Producer Single-Cast 


Requirement : 
Number Requirement 
FRS16 For single-cast safety connections, the Single-cast Safety ValidatorClient shall produce 


safety data to the Single-cast Safety ValidatorServer as defined by the Expected Packet 
Interval (EPI) rate. 


FRS18 The Single-cast safety data producer shall use the time value returned in the ping 
response (Time Coordination message) to adjust the time stamp sent the Single-cast 
produced data. 


FRS89 At each single-cast producer ping interval, the ping count shall be incremented in the next 
available safety message header. 

FRS90 The single-cast producer ping interval shall be a multiple of the EPI; ping requests shall 
be made at rates based on the Ping_Interval_EPI_Mulitplier 

FRS241 If the connection type is single-cast, the Max_Consumer_Number shall be equal to 1. 

FRS281 For Single-Cast, the flag Init_Complete_Out shall indicate that the first time coordination 


message has been received by the producer and the producer is producing data with the 
time stamp relative to the consumer’s clock. 


FRS283 For Single-Cast, the Data_Time_Stamp value shall be set to 0 by the producer until the 
first time coordination section is received. 


FRS376 The rollover count used in the Extended Format Single-Cast CRC shall be zero until the 
initial Time Coordination exchange has been completed. 


TST121 The Extended Format Single-Cast Data Production test shall establish a single-cast 
connection to the producing DUT and confirm the data is produced properly 


Required Initial Conditions: 


Test Procedure: 


1. Originate an Extended Format single-cast connection with the Producer DUT and 
provide the Initial Time Stamp and Initial Rollover Value. The connection process will 
also exchange the PID & CID between the originator and the target. 


2: The 1st single-cast message has been received by the test 
3; The test verifies the CRC calculates correctly with a 0 Rollover Value. 
4. The test verifies that the data time stamp = 0 
5. The initial ping count value is saved. 
6. The test verifies that the max consumer number = 1 
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The test responds with a valid Extended Format time coordination message. 
The 2™ data message is received. 
The test verifies that the data message was received at the EPI rate. 


10. The test confirms the CRC calculates correctly with the proper Rollover Count Value 
included 

1. The test verifies that the data time stamp value is a value that is relative to the time 

coordination message’s consumer time value 

2. As additional data messages are received, steps 7, 8, and 9 are repeated for each 
message. 

3. The test will keep a count of the data messages received. The ping count value is 

monitored and when a change is detected the test will compare the message count to the 

ping count interval value. This test will be executed for a period of time. 


The messages will continue until a Time Stamp rollover occurs. 


5. The test will confirm that the next message CRC calculates correctly with an updated 
Rollover Count Value. 


F-3.5.1.10 TST21 - Producer Run/Idle Usage 


[he Run_Idle bit is used to indicate the state of the data in the data message. This functionality 
is common to single-cast and multi-cast. 


Requirement 


Nawiber Requirement 

FRS104 Once the producer has correctly verified a successful response to a forward open 
message, the producer shall start producing safety data at the periodic rate but with the 
run/idle bit set to idle (single-cast) or the Consumer_Active_Idle set to Idle (multi-cast). 

FRS106 The producer shall maintain the run/idle or Consumer_Active_Idle bit idle until the initial 
Time Coordination sequence is successfully completed. 

FRS179 The Run_Idle bit value of 0 shall indicate Idle, and the Run_Idle bit value of | shall 
indicate Run 

FRS180 For single-cast connections, the Run_Idle bit shall be set to Idle if the producing 
application is Idle or if the producer is waiting for Time Coordination Message 
information to be received at the initiation of data production. 

FRS181 If Time Coordination Message information has been received; the Run_Idle bit shall be 
set to the Run_Idle status indicated by the producing application. 

FRS183 The N_Run_Idle complement bit shall always be the complement of the Run_Idle bit 

FRS218 If the producing application is actively controlling data the Run_Idle indication shall 


indicate Run. If the producing application is not actively controlling the data and the 
data should be put in the safety state, the Run_Idle indication shall indicate Idle. 


TST21 The Producer Run/Idle Usage Test shall confirm that the producer is controlling the 
Run/Idle indication properly . 


Required Initial Conditions: 


1. This test will function correctly for both base format and Extended Format messages 


2. A safety I/O connection must exist between the test and the Producer DUT. The 
connection process has previously exchanged the PID and CID between the originator 
and the target. 


3: The 1“ single-cast or Multi-cast message has been received by the test 
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Test Procedure: 


Tf the connection type is single-cast verify that the Run_Idle bit is set to 0. 


Tf the connection type is multi-cast, verify that the Run_Idle bit is set to the Application 
state, 


The test will send a valid time coordination message. 


The DUT will validate the time coordination message and set the Run_Idle bit to the 
application state. 


The test will receive the data message and verify that the Run_Idle bit is set to the 
Application state. 


Tf the connection type is multi-cast, the test will receive a Time Correction Packet 


Verify that the multicast active idle bit is set 


TST22 - Producer Ping Count Usage 


The Ping_Count bits are used to request time coordination messages. A time coordination 
message is expected to be received after every ping_count change. 


Requirement A 
ashes Requirement 

FRS70 Upon connection establishment, the producer shall request an initial ping response. 

FRS75 Once each Ping Interval, the producer shall request another ping response from the 
consumer. 

FRS232 The Ping_Count_Interval shall be equal to the EPI times the 
Ping_Interval_EPI_Multiplier. 

FRS233 The Ping_Count_Interval shall define the rate at which Time Coordination Messages will 
be requested and sent. 

FRS235 A legal Ping_Interval_EPI_Multiplier shall have a minimum value determined from the 
equation Max_Consumer Number*Timeout_Multiplier.PI +15, and a maximum less than 
1000. The default values shall be 100 for Multi-cast and 19 for Single Cast 

FRS239 The Ping_Interval_EPI_Multiplier shall be greater than or equal to: [{the Max 
Timeout_Multiplier.PI(C#) for all consumers} * Max_Consumer_Num] + 15 

FRS318 The Ping_Interval_EPI_Multiplier shall be set small enough to ensure that the 
Ping_Count_Interval is less than or equal to 100 seconds. 

FRS333 Producers shall allow Time Coordination responses to arrive during the Ping_interval or 
Ping_Interval + 1. 


TST22 The Producer Ping Count Usage positive test shall confirm the producer DUT is 
generating Ping Count changes properly. 


Required Initial Conditions: 


3. 


This test will support both base and Extended Format connections. 


A safety I/O connection must exist between the test and the Producer DUT. The 
connection process has previously exchanged the PID and CID between the originator 
and the target. 


A single-cast or Multi-cast message has been received by the test 


Test Procedure: 


In response to the Ist Ping Request, send a Time Coordination Response in 
Ping_Interval+1 


—F-38- 
Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Appendix F: Safety Test Plan 


F-3.5.1.12 


Confirm the Producer DUT does not close the connection 


3. The DUT sends a data message with the Ping_Count bits set to a value that will trigger a 
time coordination message to be sent. 


4. The test receives the data message and verifies the ping_count. The test will send a valid 
time coordination message. 


5 The DUT will continue to send data messages and send a ping count request at the ping 
count interval. 


6. The test will respond to ping count changes during the Ping_Interval. The test will 
monitor the time between ping count changes and compare the time to the ping count 
interval. The test received the Ping_Interval_EPI_Multiplier and the EPI values via the 
forward open. The test will calculate the ping count interval that is used for the 
comparison. 


7. The DUT will be reconfigured so that various EPI and Ping_Interval_EPI_Multiplier 
values can be tested. After each configuration steps 1 through 4 will be executed. 


8. The configurations will be chosen so that the Ping_Interval_EPI_Multiplier range will be 
tested. 


9. The configurations will be chosen so that the Ping_Count_Interval range will be tested 


TST23 - Base Format Multi-Cast Production to a Single Consumer 


The requirements that are unique to the multi-cast connection type but not specific to multiple 
consumers are verified in this test with the tester simulating 1 consumer. 


Requirement 4 
Nebee Requirement 

FRS24 The produced Multi-Cast safety data shall include a Producer_Time_Stamp with each 
safety data production. 

FRS26 The Multi-cast Consumer_Time_Values shall be used by the Multi-cast safety data 
producer to generate a Time_Correction_Value for each safety data consumer 

FRS27 A Time_Correction_Value shall be sent by the Multi-cast safety data producer to each 
safety data consumers each Ping Interval. 

FRS182 For multi- connections, the Run_Idle bit shall be set to the Run_Idle status indicated 
by the producing application. 

FRS204 The Reserved bits shall be ignored by the producer except for CRC and Ack_Byte_2 
checking. 

FRS209 The Multi_Cast_Active_Idle bit value of 0 shall indicate Idle, and the 
Multi_Cast_Active_Idle bit value of 1 shall indicate Active. 

FRS210 Once the Multi_Cast_Active_Idle bit has been set to Active after Ist data production, this 
bit shall not be set back to idle until the safety connection is re-initialized 

FRS234 The Ping_Count_Interval shall define the rate at which Time Correction sections are sent 
to each consumer. 

FRS237 All Time_Correction sections shall be sent out by the client within the Ping_Interval. 

FRS285 For Multi-Cast, the Data_Time_Stamp value shall always be set equal to the producers 
clock. 

FRS358 Multi_Cast_Active_Idle in the Time Correction message shall indicate Idle if transmitted 
before this consumer has responded with a valid time coordination message 


TST23 The Base Format Producer Multi-cast positive test shall confirm that the producer DUT 
behaves correctly when connected to 1 consumer. 
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F-3.5.1.13 


Required Initial Conditions: 


Test Procedure: 


Setup a safety I/O connection of a type supported by the DUT. 


2. The test wi 
Coordinatio 
The test wi 
4. The test wi 
a: The DUT w: 
6. The test wi 


7. The test wi 
T 


he test wi 


he test wi 


e test wi 


mn. 


ay 
ai 

11. After the ini 
T 


verify that the Time Correction message is not sent prior to the Time 


send a valid time coordination message. 
verify that the time stamp is valid 


ill send a 2nd data message. 


verify that the 2nd data message contains a valid time_correction value 


based on the consumer_time_value 


verify that the Multi_Cast_Active_Idle bit is set to 1 


he test will verify that the time stamp is valid. 


verify that the time_correction value is using the consumer_time_value. 


send a valid time coordination message. 


itialization process the time_correction data is sent at the ping_interval. 


keep a count of the data messages received. The ping count value is 


monitored and when a change is detected the test will compare the message count to the 
ping count interval value. The test will verify the time_correction value. This test will 


be executes 


for a period of time. 


TST122 - Extended Format Multi-Cast Production to a Single Consumer 


There are some special requirements for Extended Format Multi-cast connections that aren’t 
checked by TST23. This tests duplicates all the common tests from TST23 and adds the 
special steps for the Extended Format. 


Requirement A 
NaneS Requirement 

FRS24 The produced Multi-Cast safety data shall include a Producer_Time_Stamp with each 
safety data production. 

FRS26 The Multi-cast Consumer_Time_Values shall be used by the Multi-cast safety data 
producer to generate a Time_Correction_Value for each safety data consumer 

FRS27 A Time_Correction_Value shall be sent by the Multi-cast safety data producer to each 
safety data consumers each Ping Interval. 

FRS182 For multi-cast connections, the Run_Idle bit shall be set to the Run_Idle status indicated 
by the producing application. 

FRS204 The Reserved bits shall be ignored by the producer except for CRC and Ack_Byte_2 
checking. 

FRS209 The Multi_Cast_Active_Idle bit value of 0 shall indicate Idle, and the 
Multi_Cast_Active_Idle bit value of 1 shall indicate Active. 

FRS210 Once the Multi_Cast_Active_Idle bit has been set to Active after Ist data production, this 
bit shall not be set back to idle until the safety connection is re-initialized 

FRS234 The Ping_Count_Interval shall define the rate at which Time Correction sections are sent 
to each consumer. 

FRS237 All Time_Correction sections shall be sent out by the client within the Ping_Interval. 

FRS285 For Multi-Cast, the Data_Time_Stamp value shall always be set equal to the producers 


clock. 
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Requirement A 
Nariber Requirement 

FRS358 Multi_Cast_Active_Idle in the Time Correction message shall indicate Idle if transmitted 
before this consumer has responded with a valid time coordination message 

FRS377 When Extended Format multi-cast connections are originated by the consumer (i.e. multi- 
cast inputs); the target producer shall provide initialization values in the SafetyOpen 
Response. 

FRS378 The active seeding of the CRC with the rollover count in Extended Format Multi-cast 


messages shall begin immediately on first production. 


TST122 The Extended Format Producer Multi-cast positive test shall confirm that the producer 
DUT behaves correctly when connected to | consumer. 


Required Initial 


Test Procedure: 


Conditions: 


1. Setup an Extended Format safety I/O connection of a type supported by the DUT. The 
test will capture the Initial Time Stamp and Initial Rollover value in the SafetyOpen or 
Safety Forward Open response 


2s The test wi 
Rollover C 


3. The test wi 


verify that the CRC of data packet calculates correctly with the Initial 
‘ount value 


verify that the Extended Format Time Correction message is not sent prior 


to the Time Coordination. 


4. The test wi 
5: The test wil 
6. T 

7. The test wi 


je test Wi 
ie test Wi 


je test Wi 


T 

T 

T 
1. The test wi 

12. A 
The test wi 

m 
ping count 


ie test Wi 


ie test Wi 


Ex 4g 


send a valid Extended Format time coordination message. 


verify that the time stamp is valid 


¢ DUT will send a 2nd data message. 


verify that the 2nd data message contains a valid time_correction value 


based on the consumer_time_value 


verify that the Multi_Cast_Active_Idle bit is set to 1 
verify that the time stamp is valid. 
verify that the time_correction value is using the consumer_time_value. 


send a valid time coordination message. 


fter the initialization process the time_correction data is sent at the ping_interval. 


keep a count of the data messages received. The ping count value is 


onitored and when a change is detected the test will compare the message count to the 


interval value. 


verify the time_correction value. 


is test will be executed until a Time Stamp Rollover occurs. 


verify on the test data packet that the CRC calculates correctly with the 


pdated Rollover count. 
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F-3.5.1.14 | TST24 - Multi-Cast Production to Multiple Consumers 


The requirements that are unique to the multi-cast connection type and are specific to multiple 
consumers are verified in this test. The tester will simulate multiple consumers. 


Requirement 7 
Naber Requirement 

FRS23 For multi-cast safety connections the Safety ValidatorClient shall produce Safety Data to 
multiple (n = 2 to 15) Safety ValidatorServers as defined by the Expected Packet Interval 
(EPI) rate. 

FRS60 The time correction message shall be sent from a multi-cast producer to each multi-cast 
consumer, once every ping interval. 

FRS65 The Consumer_# in the Time Correction message shall indicates the number of the 
consumer that this message is directed to. 

FRS95 Time correction messages shall be sent to the multi-cast consumers at a rate to ensure that 
each consumer gets a time correction message within a single producer ping interval 

FRS96 For Non-DeviceNet networks the time correction message shall be concatenated with the 
safety data message and sent as a single message. 

FRS205 For multi-cast produced data the Multi_Cast_Active_Idle, and 
Consumer_Time_Correction_Value shall be directed to the consumer indicated by the 
Consumer_# field of the message. 

FRS242 For multi-cast connections, the legal range of Max_Consumer_Number values shall be 
from | through 15. 

FRS257 For multi-cast producers, Time Correction messages shall be sent to the n consumers. 
(where n= | thru Max_Consumer_Number), during the 8th thru n+8 EPI’s of the Ping 
Interval. 

FRS258 The Time Correction message of consumer | shall be sent first, followed by 2, 3,...,n. 

FRS358 Multi_Cast_Active_Idle in the Time Correction message shall indicate Idle if transmitted 
before this consumer has responded with a valid time coordination message 


TST24 The Multi-cast Producer to Multiple Consumer test shall confirm the requirement 
related to maintaining connections to multiple consumers. 


Required Initial Conditions: 


1. This test will function for base format and Extended Format messages 
2. The DUT should be configured to support its maximum number of consumers “if 
necessary”. 


Test Procedure: 


The test will open DUT’s maximum # of connections one at a time. 


y 


The test will emulate the DUT maximum # of consumers and will control when a 
consumer becomes active. 


The test will execute the following steps for each consumer as it becomes active. 
The DUT and test open a connection. 
The DUT produces a valid data message. 


The test receives the data message and responses with a valid time coordination message. 


Se BO 


The DUT produces the initial time correction message with the correct consumer 
number. The Multi_Cast_Active_Idle bit is set to 1 indicating that the consumer’s time 
coordination message was valid. 
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8. The test will verify the data message production at the EPI rate. 
The test will verify that the time correction message is received once every ping interval. 


0. The test will verify that the time correction messages were sent starting at the 9th 
production of the ping interval. Consumer #1 at the 9th, consumer #2 at the 10th,..., 
Consumer MAX at the (MAX+9)th production of the ping interval. 


1. The test will verify that time correction messages were sent in increasing, sequential 
order from 1 to the maximum consumer number. 


F-3.5.2 Positive Consumer Tests 


When testing a DUT consumer the tester will be the producer. The tester will generate data and 
Time Correction messages, and verify any Time Coordination message received. These tests 
will be used by both the originator and target positive test engines. 


F-3.5.2.1 TST25 - Single-cast Consumer Time Coordination Message Generation 


[he consumer must generate the time coordination message in response to a ping count change 
to maintain a connection. The tests in this section will verify a consumer DUT is properly 
generating the sections of the time coordination message. These requirements are common to 
devices and connection types. 


Requirement 7 
Number Requirement 

FRS17 The Single-cast Safety ValidatorServer shall respond to a ping request and 
produces a Time Coordination message with a Time_Value to the Single-cast 
Safety ValidatorClient that is used by the safety data producer. 

FRS48 The time coordination section shall be sent from the consumer to the producer in 
response to a change in the ping count. 

FRS52 The Parity_Even bit in the Time Coordination message shall be even parity of 
bits 0 through 6 of the message 

FRS53 The Ping_Response_Bit in the Time Coordination message shall indicate that a 
ping response is being sent 

FRSS5 Ping_Count_Reply in the Time Coordination message shall indicates which ping 
request the consumer is responding to 

FRS56 The following rule shall be used for the calculation of the parity bit in the Time 
Coordination message: Bit 7 of the Ack_Byte form even parity on the 
Ack_Byte. 

FRS57 The following rule shall be used for setting of the bits in Ack_Byte_2 of the Time 


Coordination message: Ack_Byte_2 = ((Ack_Byte XOR 0xFF)AND 
0x55)OR(Ack_Byte AND OxAA) 

FRS58 The Time Coordination CRC calculation shall include: Consumer Identifier 
(CID) (by CRC-S3 or CRC-S5), Ack Byte (by CRC-S3 or CRC-SS), 
Consumer_Time_Value (by CRC-S3 or CRC-S5) 


FRS59 Ack_Byte_2 in the Base Time Coordination message shall not be included in the 
Safety CRC 
FRS71 When the consumer sees a change in the ping count, the consumer shall prepare a 


Time Coordination response message that contains the consumer’s value of its 
clock count 


FRS142 The Safety ValidatorServer shall perform Ping_Count checking on every message 
FRS203 The Time Coordination Reserved bits shall be set to 0 by the consumer. 
FRS291 A consumer of safety data shall be able to detect when the Ping_Count has 
changed. 
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F-3.5.2.2 


Requirement x 
Number Requirement 
FRS332 If a Safety ValidatorServer detects that the ping count has changed, it shall 


produce a time coordination message within that Ping Interval or within 5 
seconds, whichever is less. 


FRS370 When a connection is established with the Extended format, the EF Time 
Coordination format shall be used; otherwise the base format shall be used. 


TST25 The Time Coordination generation test is a positive test which shall confirm that the 
Time Coordination messages are generated properly by the consumer DUT. 


Required Initial Conditions: 


This test will function for both the EF and base format connections 
Set up a safety I/O connection with the DUT 

3. The connection process exchanged the PID and CID between the originator and the 
target. 

Test Procedure: 


Send a data message with a ping count change 


2. The test will confirm a Time Coordination response is sent. The connection is fully 
established. 


3: Confirm the Parity bit is correct for even parity in bit 7 of Ack_Byte 


Tf the base format is being used, confirm that Ack_Byte_2 algorithm generated the 
correct value 


5. Confirm that the Ping count is equal to the ping count value sent 
Confirm that the Reserved bits 4, 5, & 6 are set to 0 
Tf the base format is being used, confirm the CRC includes the CID and CID excludes 
the Ack_Byte 2 


TST26 - Consumer Positive CRC/PID/CID Test 


A number of requirements are confirmed by simply communicating with the DUT without 
errors. 


The Producer ID (PID) is the initial seed value for the safety CRC’s of all messages from the 
data producer of a connection. The Consumer ID (CID) is the initial seed value for the safety 
CRC’s of all messages from the consumer of a connection. Every message that is transmitted or 
received will have the safety CRC verified. 


Requirement rs 
Namber Requirement 

FRS32 All safety messages and safety response messages shall be encoded with 
the safety CRC’s defined in Appendix E 

FRS142 The Safety ValidatorServer shall perform Ping_Count checking on every 
message 

FRS155 The Producer Identifier (PID) shall be used as an initial seed value in the 
CRCs in the runtime protocol. 

FRS156 The Consumer shall obtain the Producer Identifier from either the 
SafetyOpen or SafetyOpen response (depending upon originator) and use 
the value as an initial seed in runtime checking the safety CRCs. 
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F-3.5.2.3 


Requirement A 
NabGe Requirement 
FRS291 A consumer of safety data shall be able to detect when the Ping_Count has 
changed. 
FRS330, The Consumer Identifier (CID) shall be used as an initial seed value in the 
CRC in the Time Coordination message. 
SRS152 During connection establishment the producing and consuming nodes shall 


exchange their respective PID/CID information (Vendor ID + Device 
Serial Number + Connection Serial Number). The originator sends its ID 
in the SafetyOpen request, and the target returns its ID as part of the 
SafetyOpen Success response. 


SRS178 The PID shall be used to seed Data production CRCs and Time Correction 
CRC, and the CID shall be used to seed the Time Coordination CRC. 


TST26 The Consumer Positive Run-time Test shall be a positive test to confirm that the 
consumer DUT is both creating proper safety CRCs with the CID and interpreting valid safety 
CRCs with PID. 


Required Initial Conditions: 


1. This test will function for both the EF and base format connections 

2: A connection must exist between the tester and the DUT. The connection process has 
previously exchanged the PID/CID from the originator to the target. 

Test Procedure: 

1. All messages received from the DUT will have the safety CRC’s recalculated with the 
CID and the received data. 
The safety CRC’s will be verified to be equal. 
All messages transmitted to the DUT will have the safety CRC’s calculated with the PID 
by the test. 


This test will not generate CRC error conditions or confirm such detection at the DUT. While 
this test is running, no error or faults should be generated by the DUT 


TST27 - Multi-cast Consumer Time Coordination Message Generation Test 


The consumer must generate the time coordination message in response to a ping count change 
within specific time windows in the Ping Interval. The tests in this section will verify a 
consumer DUT is properly generating the sections of the time coordination message and at the 
proper time. 


Requirement i 
iNamber Requirement 

FRS25 The Multi-Cast Safety ValidatorServers shall respond to a ping request by sending a Time 
Coordination message with a Consumer_Time_Value to the Safety ValidatorClient. 

FRS94 All multi-cast consumers shall respond to a change in the ping request value, consumers 
other than consumer | shall wait Consumer_Number -| times the EPI to reply. 

FRS148 Multicast-consumers connecting to an existing producer shall send the 
Time_Coordination message immediately upon the first valid reception. 

FRS332 If a Safety ValidatorServer detects that the ping count has changed, it shall produce a time 
coordination message within that Ping Interval or within 5 seconds, whichever is less. 


—F-45- 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Appendix F: Safety Test Plan 


F-3.6 


F-3.6.1 


TST27 The Multi-cast Time Coordination Spread Test shall confirm the DUT multi-cast 


consumer will properly respond in an EPI slot consistent with its < 


signed consumer # 


Required Initial Conditions: 


l. 


This test will function for both the EF and base format connections 


Test Procedure: 


Set up the DUT to Establish a safety I/O connection with the tester 

Assign it an initial consumer # of 1 

Trigger a ping count change 

Run TST25 — Single-cast Consumer Time Coordination Message Generation 

Run TST26 — Consumer Positive CRC/PID/CID Test 

Confirm a Time coordination response is generated immediately 

Continue communication at the next ping interval generate another ping count change 
Confirm the Time Coordination response is generated in the correct time slot 


Stop producing data long enough for the DUT to close the connection and attempt to re- 
establish 


Repeat from step 1 with consecutively increasing consumer # assignments from 1 — 15 


Confirm that the ping responses are initially immediate and then subsequently delayed to 
Consumer # - 1 data productions 


Common Negative Consumer Tests 


This section will define behavior that is common to all devices regardless of what subset of 
Safety Functionality is implemented. In other words, all safety devices must pass the tests 
described in this section. 


TST28 - Base Format Incorrect Sequence/Insertion Detection 


RETEURE TE Requirement 
Number a 
FRS84 Consumers using base format connections shall see the Timestamp increase for each 
successive period or the connection shall be terminated 
FRS299 The Last_Data_Time_Stamp shall be used to detect out of sequence messages 


TST28 The Base Format Incorrect Sequence/Insertion Detection test shall confirm that the 
DUT detects non-consecutive Time Stamps and treats these as errors. 


aac 


Set up a safety I/O connection of a type supported by the DUT 


The establishment of a safety I/O connection is a positive test case for the Time_Stamp 
generation. 


The test will calculate the data age for each packet to verify the Time_Stamp correctness. 
The connection will run for a set period of time. 


The Time_Stamp register/counter is a cyclic counter and will rollover. At the rollover 
condition the most recent Time_Stamp will be less than the previous Time_Stamp. The 
data age check will verify this rollover condition. 


Send a Time_Stamp value that is less than the current Time_Stamp value. 
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Fhe Verify that the connection is terminated. 


8. The test will define expected fail-safe behavior 


F-3.6.2 TST112 —- Extended Format Incorrect Sequence/Insertion Detection 


Requirement 7" 
Requiremen 
Number COEENERE 

FRS372 Consumers using Extended Format connections shall see the Timestamp increase for 
each successive period. If the consumer receives a packet with an out-of-sequence 
Timestamp, it shall drop the packet unless the Consumer Fault Counter has reached the 
Max Fault Number; in which case the connection shall be terminated. 

FRS299 The Last_Data_Time_Stamp shall be used to detect out of sequence messages 

FR375 When the connection is a EF Consuming connection, the Producer/Consumer Fault 
Counter attribute shall reflect the Consumer_Fault_Counter. When the connection is a 
EF Producing connection, the attribute shall reflect the Producer_Fault_Counter. 


TST112 The Extended Format Incorrect Sequence/Insertion Detection test shall confirm that 
the DUT detects non-consecutive Time Stamps and drops the packet until the Max Fault Count 
is reached, then terminates the connection. 


The following procedure will be followed: 


1. Set up a EF safety I/O connection of a type supported by the DUT with a 
Max_Fault_Number = 5. 


2: The establishment of a safety I/O connection is a positive test case for the Time_Stamp 
generation. 


The test will calculate the data age for each packet to verify the Time_Stamp correctness. 
The connection will run for a set period of time. 


Guy eG. 


The Time_Stamp register/counter is a cyclic counter and will rollover. At this point, the 
producer and consumer should have incremented their rollover counter. At the rollover 
condition the most recent Time_Stamp will be less than the previous Time_Stamp. 


6. Send a Time_Stamp value that is less than the current Time_Stamp value for 
(Max_Fault_Number — 1) times. 


as Verify that the packet is dropped by inspecting the Producer/Consumer Fault Count 
attribute of the Safety Validator, but the connection is maintained. 


8. Send one more Time_Stamp values less than the current Time_Stamp 
9. Verify that the connection is terminated 


F-3.6.3 TST29 - Message Corruption Detection 


Requirement 
Number 


Requirement 


FRS5S A message corruption shall be detected when the data and CRC-Sx are calculated and 
compared. This error shall cause the connection to be: 

Terminated 

IF (Base format) OR (Extended Format AND Consumer_Fault_Count) > 
Max_Fault_Number 

OR 

Dropped 

IF Extended Format AND Consumer_Fault_Count < Max_Fault_Number.. 


FRS6 A corrupted message that was not detected by the link or CRC-Sx check (i.e., error that 
exceeded the Hamming distance of CRC) shall be detected when the actual and 
complemented copies of the data are compared in the consumer. 
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F-3.6.4 


Requirement 


Number Requirement 


FRS86 If the transmitted CRC-Sx and data are checked and any found to be in error or the data 


cross-check is found to be in error, the consumer shall either drop the packet (Extended 
Format AND Consumer_Fault_Count < Max_Fault_Count), or terminate the connection 
and go to the defined safety state (Base format or Extended Format AND 
Consumer_Fault_Count > Max_Fault_Count). 


FRS375 When the connection is a EF Consuming connection, the Producer/Consumer Fault 


Counter attribute shall reflect the Consumer_Fault_Counter. When the connection is a 
EF Producing connection, the attribute shall reflect the Producer_Fault_Counter. 


TST29 The Message Corruption Detection test shall set up a safety I/O connection of a type 
supported by the DUT and simulate corruption by setting invalid Safety CRCs. 


Initial conditions: 


1. 
2. 


This test will support both the EF and base format connections 
Run SPTE as a target 


The following procedure will be followed: 


ey 


Se See oy 


Establish a standard format connection (if supported) 
Send a data packet with a corrupt Data CRC 
Verify that the connection is terminated. 


Repeat the procedure for the complement data CRC, the Time Stamp CRC, Time 
Correction and the complemented data. 


If the DUT supports Multi-cast consumer connections, repeat the test with the Time 
Correction message 


Establish a High-Availability format connection (if supported) 

Send a data packet with a corrupt Data CRC for Max_Fault_Count — | times 
Verify that the packet is dropped and connection continued. 

Send a data packet with a corrupt Data CRC one more time 

Verify that the connection is terminated 


Repeat the procedure for the complement data CRC, the Time Stamp CRC, Time 
Correction and the complemented data. 

If the DUT supports Multi-cast consumer connections, repeat the test with the Time 
Correction message 


TST30 - Message Delay Detection by Consumers 


Requirement 


Number Requirement 


FRS3 


The safety protocol requires messages to occur within defined time expectations. 
Messages received later than these time expectations shall be treated as errors, resulting 
in the connection's termination. 


FRS74 The consumer shall use the value received from the producer to calculate the age of the 


data by subtracting the producer’s time stamp from its current clock count. If the 
calculated delta is less than the maximum delta specified by the user, the data is ok and 
the data is used by the application within the device. If the delta is greater than the user 
specified value, the data is deemed to be too old to use and the connection is terminated. 


FRS80. All consumers shall check the age of the data received by checking the time stamps 
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F-3.7 
F-3.7.1 


Requirement : 
Number Requirement 
received. 
FRS87 If a message is delayed such that it is received 


1. beyond the consumer activity monitor (link-triggered application) or 
2. the data age exceeds the network time expectation, 


then all further messages are ignored, and the connection shall be terminated. 


types supported by 


Initial conditions: 


[ST30 The Message Delay Detection Test shall set up a safety consumer connections of all 


the DUT and send data at a rate that exceeds the agreed upon EPI. 


This test will support both the EF and base format connection 
The following procedure will be followed: 


Set up a safety I/O connection of a type supported by the DUT 


2: The establishment of a safety I/O connection is a positive test case for the message 
timing. 

3. The connection will run for a set period of time. 

4. Begin delaying the packet delivery until it exceeds the period set by the Network Time 
Expectation Multiplier. 

5. Verify that the connection is terminated at a time less than or equal to the Network Time 
Expectation time. 


Common Negative Producer Tests 


TST31 - Base Format Producer Time Coordination Response Failure 


Requirement . 
Nuun bes: Requirement 

FRS10 When a producer detects an error that requires connection termination it shall terminate 
the connection, and notify the application of the action. 

FRSS2 The Parity_Even bit in the Time Coordination message shall be even parity of bits 0 
through 6 of the message 

FRSS3 The Ping_Response_Bit in the Time Coordination message shall indicates that a ping 
response is being sent 

FRS55 Ping_Count_Reply in the Time Coordination message shall indicates which ping request 
the consumer is responding to 

FRS56 The following rule shall be used for the calculation of the parity bit in the Time 
Coordination message: - Bit 7 of the Ack_Byte form even parity on the Ack_Byte. 

FRS5S7 The following rule shall be used for setting of the bits in Ack_Byte_2 of the Time 
Coordination message: Ack_Byte_2 = ((Ack_Byte XOR 0xFF)AND 
0x55)OR(Ack_Byte AND 0xAA) 

FRSS8 The Time Coordination CRC calculation shall include: 
Consumer Identifier (CID) (by CRC-S3 or CRC-S5) 
Ack Byte (by CRC-S3 or CRC-S5) 
Consumer_Time_Value (by CRC-S3 or CRC-S5) 

FRS59 Ack_Byte_2 in the Time Coordination message shall not be included in the Safety CRC 

FRS98, If a multi-cast time coordination message is lost or delayed past the 


(Timeout_Multiplier.PI +2) ping intervals, an error shall be generated and the connection 
closed 
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Requirement r 
Number Requirement 

FRS195 If the Ping_Response bit is 1, it shall indicate that the Consumer_Time_Value, and 
Ping_Count_Reply, are valid on this production 

FRS196, Tf the Ping_Response bit is 0, it shall indicate that the Consumer_Time_Value, and 
Ping_Count_Reply, are not valid on this production and should be ignored. 

FRS229 The Timeout_Multiplier shall be used to determine how many ping intervals 
(Timeout_Multiplier.PI+2) a producer will wait before faulting a consumer who has 
failed to send a Time Coordination response to a Ping request 

FRS374 For the Base Format, Timeout_Multiplier.PI shall be equal to the Timeout_Multiplier. 
For the HiAvailabilityFormat, Timeout_Multiplier.PI shall be equal to the smaller of 
Timeout_Multiplier or 4, whichever is lower. 

FRS333 Producers shall allow Time Coordination responses to arrive during the Ping_interval or 
Ping_Interval + 1. 

TST31 The Producer Time Coordination Failure Response test shall confirm that the producer 
DUT performs proper safety-state behavior when communication failures are detected. 


Required Initial Conditions: 


1. Run SPTE as an originator and configure it with a safety I/O connection of a type 
supported by the DUT 


Test Procedure: 

1. In response to the 1st Ping Request, send a Time Coordination Response in 
Timeout_Multiplier.PI + 1 Ping_Intervals 
Confirm the Producer DUT does not close the connection 


In response to the on Ping Request, send a Time Coordination Response in 
Timeout_Multiplier.PI + 2 Ping_Intervals 


Confirm the producer does not closes the connection 
Ignore all ping requests and send no Time Coordination responses 


Confirm the producer faults and closes the connection after Timeout_Multiplier.PI+2 
Ping_Intervals 


Re-establish the connection 


8. Send Time_Coordination responses with Ping_Response bit cleared. 


Confirm the producer faults and closes the connection after Timeout_Multiplier.PI+2 
Ping_Intervals 


10.  Re-establish the connection 


11. Set the Parity_Even bit to an incorrect value. 


12. The producer will detect the incorrect Time Coordination Message and terminate the 
connection. 


13. Re-establish the connection. 
14. Set up a safety I/O connection of a type supported by the DUT 
15. Send a valid Time Coordination Message. 


16. The producer will calculate the Time Coordination Message using the data received in 
the data packet. Compare the calculated CRC to the received CRC. The values should be 
equal. 
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17. Send an invalid Time Coordination Message. Calculate the CRC using the Ack_Byte_2. 


18. | The producer will calculate the Time Coordination Message using the data received in 
the data packet including excluding the Ack_Byte_2. Compare the calculated CRC to the 
received CRC. The values should be unequal. 


19. The producer will detect the incorrect Time Coordination Message and terminate the 
connection 


20. Re-establish the connection 
21. Generate a Time Coordination Message with an incorrect Ping_Count_Reply. 


22. The producer DUT will detect the incorrect Time Coordination Message with the wrong 
Ping_Count_Reply. The producer will terminate the connection. 


23.  Re-establish the connection. 


24. Generate a Time Coordination Message with an incorrect Ack_Byte_2 value. 


25. The producer DUT will detect the incorrect Ack_Byte_2 value and terminate the 
connection. 


26. Re-establish the connection. 


27. Generate a Time Coordination Message with an incorrect Time Coordination Message 
CRC. The CRC will be calculated without the Connection Originator Identifier. 


28. The producer will detect the incorrect Time Coordination Message CRC and terminate 
the connection. 


Because Time Coordination Responses are common to both Multi-cast and Single-cast, this test 
applies to both I/O types and if a DUT supports both types of Safety producer, the test shall be 
executed for both. 


F-3.7.2 TST116 - Extended Format Producer Time Coordination Response Failure 


Requirement A 
Naniber Requirement 

FRS10 When a producer detects an error that requires connection termination it shall terminate 
the connection, and notify the application of the action. 

FRS52 The Parity_Even bit in the Time Coordination message shall be even parity of bits 0 
through 6 of the message 

FRS53 The Ping_Response_Bit in the Time Coordination message shall indicates that a ping 
response is being sent 

FRS55 Ping_Count_Reply in the Time Coordination message shall indicates which ping request 
the consumer is responding to 

FRS5S6 The following rule shall be used for the calculation of the parity bit in the Time 
Coordination message: - Bit 7 of the Ack_Byte form even parity on the Ack_Byte. 

FRS58 The Time Coordination CRC calculation shall include: 

Consumer Identifier (CID) (by CRC-S3 or CRC-S5) 
Ack Byte (by CRC-S3 or CRC-S5) 
Consumer_Time_Value (by CRC-S3 or CRC-S5) 

FRS98 If a multi-cast time coordination message is lost or delayed past the 
(Timeout_Multiplier.PI +2) ping intervals, an error shall be generated and the connection 
closed 

FRS195 If the Ping_Response bit is 1, it shall indicate that the Consumer_Time_Value, and 
Ping_Count_Reply, are valid on this production 

FRS196 If the Ping_Response bit is 0, it shall indicate that the Consumer_Time_Value, and 
Ping_Count_Reply, are not valid on this production and should be ignored. 
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Requirement ; 
Number Requirement 
FRS229 The Timeout_Multiplier shall be used to determine how many ping intervals 


(Timeout_Multiplier.PI+2) a producer will wait before faulting a consumer who has 
failed to send a Time Coordination response to a Ping request 

FRS374 For the Base Format, Timeout_Multiplier.PI shall be equal to the Timeout_Multiplier. 
For the HiAvailabilityFormat, Timeout_Multiplier.PI shall be equal to the smaller of 
Timeout_Multiplier or 4, whichever is lower. 


FRS333 Producers shall allow Time Coordination responses to arrive during the Ping_interval or 
Ping_Interval + 1. 


TST116 The Extended Format Producer Time Coordination Failure Response test shall confirm 
that the producer DUT performs proper behavior when packet errors are detected. 


Required Initial Conditions: 


1. Run SPTE as an originator and configure it with a safety I/O connection of a type 
supported by the DUT 


Test Procedure: 

1. In response to the Ist Ping Request, send a Time Coordination Response in same 
Ping_Interval 
Confirm the Producer DUT does not close the connection 


3. In response to the 2" Ping Request, send a Time Coordination Response in the next 
Ping_Interval 


Confirm the producer does not closes the connection 
Ignore all ping requests and send no Time Coordination responses 


Confirm the producer faults and closes the connection after Timeout_Multiplier.PI+2 
Ping_Intervals 


Re-establish the connection 


Send Time_Coordination responses with Ping_Response bit cleared 


Confirm the producer faults and closes the connection after Timeout_Multiplier.PI+2 
Ping_Intervals 


0. Re-establish the connection 


1. Send Time Coordination responses with an incorrect Parity_Even bit for 
(Max_Fault_Count) or (Timeout_Multiplier.PI+2) times; whichever is less 


2. Verify that the producer closes the connection after the last transmission but not the prior 
ones. 


Re-establish the connection. 
4. Send a valid Time Coordination Message. 


The producer will calculate the Time Coordination Message using the data received in 
the data packet. Compare the calculated CRC to the received CRC. The values should be 
equal. 
6. Generate a Time Coordination Message with an incorrect Ping_Count_Reply for 
(Max_Fault_Count) or (Timeout_Multiplier.PI+2) times; whichever is less. 


7. Verify that the producer does not close the connection after the last transmission but not 
the prior ones. 
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F-3.7.3 


18.  Re-establish the connection. 

19. Generate a Time Coordination Message with an incorrect Time Coordination Message 
CRC for (Max_Fault_Count) or (Timeout_Multiplier.PI+2) times; whichever is less. 

20. Verify that the producer does not close the connection after the last transmission but not 
the prior ones. 


Because Extended Format Time Coordination messages are common to both Multi-cast and 
Single-cast, this test applies to both I/O types and if a DUT supports both types of Safety 
producer, the test shall be executed for both. 


TST32 - Producer Time Coordination No-response 


The Timeout_Multiplier value is a common parameter for the producer and consumer. This 
parameter is part of the forward open request. The producer uses it to determine the number 
Ping_Intervals it will wait for a time coordination message before a fault occurs. This 
behavior is common to multi-cast or single-cast connections in both Base and Extended 
Formats. 


Requirement 
Number 
FRS229 The Timeout_Multiplier shall be used to determine how many ping intervals 
(Timeout_Multiplier.PI+2) a producer will wait before faulting a consumer who has 
failed to send a Time Coordination response to a Ping request 
FRS374 For the Base Format, Timeout_Multiplier.PI shall be equal to the Timeout_Multiplier. 


For the HiAvailabilityFormat, Timeout_Multiplier.PI shall be equal to the smaller of 
Timeout_Multiplier or 4, whichever is lower. 


Requirement 


TST32 The Producer Timeout Multiplier Margin Test shall confirm that if a consumer never 
returns a Time Coordination message, the producer faults the connection within Timeout 
Multiplier.PI+2 Ping Intervals 


Required Initial Conditions: 


1. This test supports both the base format and the Extended Format. It will use the 
fimeout_Multiplier.PI enhanced definition. 


2. The DUT will be configured to support 15 consumers. 
33 The Timeout_Multiplier in the connection request will be varied from 1 to 4 for each 
base format consumer or | to 6 for Extended Format consumers. 


Test Procedure: 

1. A connection will be established using the base or Extended Format depending on which 
‘ormat is being tested. 

The test will not send Time Coordination responses to Ping Requests 


3. As the consumer connection is faulted, the test will verify that the producer detected the 
ault at Timeout_Multiplier.PI+ 2 Ping_Intervals. This will be detected by seeing that 
ing requests for that consumer # are no longer requested, or data is no longer produced. 


4. Steps 1-3 will be repeated for all the Timeout_Multiplier values based on format type. 
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F-3.8 Single_Cast Consumer Negative Tests 
F-3.8.1 | TST33 - Base Format Single-Cast Consumer Test; >= 3 Bytes, Negative 
Requirement 4 
ashes Requirement 
FRS7 The PID or CID is incorporated within the Safety CRC calculation in both the producer 
and the consumer, thus, if a message is mistakenly received, it shall be detected when the 
CRC is checked. 
FRS9 The following Sequence of checks shall be used to check messages: 


Ping count check 

Evaluate Time stamp section CRC 
Evaluated Time Stamps 

Evaluate Actual Data CRC 
Evaluate Complement Data CRC 
Perform Cross-Check 


FRS13 When crosschecked safety data are found to be different, the data is treated as faulty. The 
base format consumer shall terminate the connection and the Extended Format consumer 
will increment the Consumer_Fault_Count and drop the packet if the count is less than 
the Max_Fault_Number, or terminate the connection if is equal to or greater than the 
Max_Fault_Number. 


FRS17 The Single-cast Safety ValidatorServer shall respond to a ping request and produces an 
Time Coordincation message with a Time_Value to the Single-cast 
Safety ValidatorClient that is used by the safety data producer. 


FRS48 The time coordination section shall be sent from the consumer to the producer in 
response to a change in the ping count. 

FRS71 When the consumer sees a change in the ping count, the consumer shall prepare a Time 
Coordination response message that contains the consumer’s value of its clock count 

FRS156 The Consumer shall obtain the Producer Identifier from the SafetyOpen and use the 
value as an initial seed in runtime checking the safety CRCs. 

FRS190 The Reserved bits shall be ignored by the consumer except for CRC checking and 
Actual/Complement checking of the TBD_Bit/N_TBD_Bit pair. 

FRS191 The N_TBD_Bit complement bit shall always be the complement of the TBD_Bit 


TST33 The Base format Single-cast Consumer test shall test all the basic features of the safety 
protocol for messages with >3 bytes of data by injecting error in each component listed in the 
above requirement. 


Required Initial Conditions: 
1; Run SPTE as a target 


Test Procedure: 


1. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 

2: The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 

3. The connection will run for a set period of time. 


The producer will send an incorrect Time Stamp CRC. 


ae The consumer will detect the error and the connection will be terminated. 


—F-54- 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Appendix F: Safety Test Plan 


6. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


di The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 
8. The producer will send an out of sequence Time Stamp. 


The consumer will detect the error and the connection will be terminated. 


0. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


1. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


2. The producer will send an incorrect Data CRC. 
The consumer will detect the error and the connection will be terminated. 


4. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


5. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


6. The producer will send an incorrect Complemented Data CRC. 
7. The consumer will detect the error and the connection will be terminated. 


Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


9. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


20. The producer will send a Data and Complemented Data mismatch. 
21. The consumer will detect the error and the connection will be terminated. 


22. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


23. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


24. The producer will send a TBD_Bit and N_TBD_Bit mismatch. 

25. The consumer will detect the error and the connection will be terminated 

26. Re-establish the connection with the DUT 

27. Valid Safety data will be sent, but with an invalid Producer ID being used to seed the 
safety CRC 
28. The consumer will detect the error and the connection will be terminated. 
29. Set up a safety I/O connection of a type supported by the DUT. 

30. Invalidate the N_Run_Idle bit in the mode byte 

31. The consumer will detect the error and the connection will be terminated. 


F-3.8.2 TST123 — Extended Format Single-Cast Consumer Test; >= 3 Bytes, Negative 
Requirement 
Number 


FRS7 The PID or CID is incorporated within the Safety CRC calculation in both the producer 
and the consumer, thus, if a message is mistakenly received, it shall be detected when the 


Requirement 
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Requirement 


Number Requirement 


CRC is checked. 


FRS9 The following Sequence of checks shall be used to check messages: 


Ping count check 

Evaluate Time stamp section CRC 
Evaluated Time Stamps 

Evaluate Actual Data CRC 
Evaluate Complement Data CRC 
Perform Cross-Check 


FRS13 When crosschecked safety data are found to be different, the data is treated as faulty. The 


base format consumer shall terminate the connection and the Extended Format consumer 
will increment the Consumer_Fault_Count and drop the packet if the count is less than 
the Max_Fault_Number, or terminate the connection if is equal to or greater than the 
Max_Fault_Number. 


FRSI7 ‘The Single-cast Safety ValidatorServer shall respond to a ping request and produces an 


Time Coordincation message with a Time_Value to the Single-cast 
Safety ValidatorClient that is used by the safety data producer. 


FRS48 The time coordination section shall be sent from the consumer to the producer in 


response to a change in the ping count. 


FRS71 When the consumer sees a change in the ping count, the consumer shall prepare a Time 


Coordination response message that contains the consumer’s value of its clock count 


FRS156 The Consumer shall obtain the Producer Identifier from the SafetyOpen and use the 


value as an initial seed in runtime checking the safety CRCs. 


FRS190 The Reserved bits shall be ignored by the consumer except for CRC checking and 


Actual/Complement checking of the TBD_Bit/N_TBD_Bit pair. 


FRS191 The N_TBD_Bit complement bit shall always be the complement of the TBD_Bit 


TST123 The Extended Format Single-cast Consumer test shall test all the basic features of the 
Extended Format for messages with >3 bytes of data by injecting error in each component 
listed in the above requirement. 


Required Initial Conditions: 


1. 


Run SPTE as a target 


Test Procedure: 


O05 ON 


Run TST29 for a Extended Format Single-cast connections with a size >3 bytes 


Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


The producer will send a Data and Complemented Data mismatch for Max_Fault_Count 
— | times. 


Verify that the packet is dropped and connection continued. 
Send a data packet with mismatched data one more time 
Verify that the connection is terminated. 


Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 
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F-3.8.3 


9. The establishment of a safety I/O connection is a positive test case when the DUT is a 


consumer. 


times. 
Verify that tl 
Send a data 
Verify that tl 
Re-establish 
Valid Safety 


Pe 


2 


Verify that 
Send a data 
18. Verify that t 


20. — Invalidate th 
21. Verify that tl 
22. Senda data 
23. Verify that tl 
24. Re-establish 
25. Valid Safety 


The producer will send a TBD_Bit and N_TBD_Bit mismatch for Max_Fault_Count — 1 


e packet is dropped and connection continued. 

packet with send a TBD_Bit and N_TBD_Bit mismatch one more time 
e connection is terminated 

the connection with the DUT 


data will be sent, but with an invalid Producer ID being used to seed the 


safety CRC for Max_Fault_Count — | times. 


e packet is dropped and connection continued. 
packet with invalid Producer ID one more time 
e connection is terminated 


Set up a safety I/O connection of a type supported by the DUT. 


i¢ N_Run_Idle bit in the mode byte for Max_Fault_Count — 1| times. 
ie packet is dropped and connection continued. 

packet with invalid N_Run_Idle bit one more time 

e connection is terminated 

the connection with the DUT 


data will be sent, but with an invalid Rollover Count being used to seed the 


safety CRC for Max_Fault_Count — | times. 


26. Verify that tl 
27. Senda data 
28. Verify that t 


TST34 - Base fo: 


e packet is dropped and connection continued. 
packet with invalid Rollover Count one more time 


e connection is terminated 


rmat Single-Cast Consumer; <= 2 Bytes, Negative 


Requirement : 
Number Requirement 

FRST The PID or CID is incorporated within the Safety CRC calculation in both the producer 
and the consumer, thus, if a message is mistakenly received, it shall be detected when the 
CRC is checked. 

FRS9 The following Sequence of checks shall be used to check messages: 
Ping count check 
Evaluate Time stamp section CRC 
Evaluated Time Stamps 
Evaluate Actual Data CRC 
Evaluate Complement Data CRC 
Perform Cross-Check (when appropriate) 

FRS1I7 The Single-cast Safety ValidatorServer shall respond to a ping request and produces an 
Time Coordincation message with a Time_Value to the Single-cast 
Safety ValidatorClient that is used by the safety data producer. 

FRS48, The time coordination section shall be sent from the consumer to the producer in 
response to a change in the ping count. 

FRS71 When the consumer sees a change in the ping count, the consumer shall prepare a Time 


Coordination response message that contains the consumer’s value of its clock count 
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Requirement A 
Namba Requirement 
FRS156 shall obtain the Producer Identifier from the SafetyOpen and use the 
value as an initial seed in runtime checking the safety CRCs. 
FRS190. The Reserved bits shall be ignored by the consumer except for CRC checking and 
Actual/Complement checking of the TBD_Bit/N_TBD_Bit pair. 
FRS191 The N_TBD_Bit complement bit shall always be the complement of the TBD_Bit 


TST34 The Base format Single-cast Consumer test shall test all the basic features of the safety 
protocol for message < 3 bytes in size by injecting error in each component listed in the 
requirements. 


Required Initial Conditions: 

1. Run SPTE as a target 

Test Procedure: 

ihe Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 1 or 2 bytes. 


2. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


¢ connection will run for a set period of time. 
The producer will send an incorrect Time Stamp CRC. 


he consumer will detect the error and the connection will be terminated. 


By 


Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 2 bytes or smaller. 

he The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 

The producer will send an out of sequence Time Stamp. 


[he consumer will detect the error and the connection will be terminated. 


0. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 2 bytes or smaller. 


[he establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


The producer will send an incorrect Data CRC. 


3. The consumer will detect the error and the connection will be terminated. 


4. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 2 bytes or smaller. 


5. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


6. The producer will send a TBD_Bit and N_TBD_Bit mismatch. 
7. The consumer will detect the error and the connection will be terminated 
8. Re-establish the connection with the DUT 
9. Valid Safety data will be sent, but with an invalid Producer ID being used to seed the 
safety CRC 
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20. The consumer will detect the error and the connection will be terminated. 
21. Set up a safety I/O connection of a type supported by the DUT. 
22. Invalidate the N_Run_Idle bit in the mode byte 


23. The consumer will detect the error and the connection will be terminated. 


F-3.8.4 TST124 —- Extended Format Single-Cast Consumer; <= 2 Bytes, Negative 


Requirement 


Number Requirement 


FRST The PID or CID is incorporated within the Safety CRC calculation in both the producer 
and the consumer, thus, if a message is mistakenly received, it shall be detected when the 
CRC is checked. 


FRS9 The following Sequence of checks shall be used to check messages: 
Ping count check 

Evaluate Time stamp section CRC 

Evaluated Time Stamps 

Evaluate Actual Data CRC 

Evaluate Complement Data CRC 

Perform Cross-Check (when appropriate) 


FRS17 The Single-cast Safety ValidatorServer shall respond to a ping request and produces an 
Time Coordincation message with a Time_Value to the Single-cast 
Safety ValidatorClient that is used by the safety data producer. 


FRS48, The time coordination section shall be sent from the consumer to the producer in 
response to a change in the ping count. 


FRS7I When the consumer sees a change in the ping count, the consumer shall prepare a Time 
Coordination response message that contains the consumer’s value of its clock count 


FRS156 The Consumer shall obtain the Producer Identifier from the SafetyOpen and use the 
value as an initial seed in runtime checking the safety CRCs. 


FRS190 The Reserved bits shall be ignored by the consumer except for CRC checking and 
Actual/Complement checking of the TBD_Bit/N_TBD_Bit pair. 


FRS191 The N_TBD_Bit complement bit shall always be the complement of the TBD_Bit 


TST124 The Extended Format Single-cast Consumer test shall test all the basic features of the 
safety protocol for message < 3 bytes in size by injecting error in each component listed in the 
requirements 


Required Initial Conditions: 
1. Run SPTE as a target 
Test Procedure: 


1. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 1 or 2 bytes. 


pas The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 

3. The connection will run for a set period of time. 

4. The producer will send an out of sequence Time Stamp for Max_Fault_Count - 1 times. 

5. Verify that the packet is dropped and connection continued. 

6. Send a data packet with an out of sequence Time Stamp one more time 
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Verify that the connection is terminated. 
The consumer will detect the error and the connection will be terminated. 


Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 2 bytes or smaller. 


0. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 
1. The producer will send an incorrect Data CRC for Max_Fault_Count — | times. 
2. Verify that the packet is dropped and connection continued. 
3. Send a data packet with an incorrect Data CRC more time 
4. Verify that the connection is terminated. 
5. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 2 bytes or smaller. 
16. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 
7. The producer will send a TBD_Bit and N_TBD_Bit mismatch for Max_Fault_Count — | 
times. 
8. Verify that the packet is dropped and connection continued. 
9. Send a data packet with a TBD_Bit and N_TBD_Bit mismatch one more time 
20. Verify that the connection is terminated. 
21. Re-establish the connection with the DUT 
22. Valid Safety data will be sent, but with an invalid Producer ID being used to seed the 
safety CRC for Max_Fault_Count — | times. 
23. Verify that the packet is dropped and connection continued. 
24. Send a data packet with an invalid Producer ID one more time 
25. Verify that the connection is terminated. 
26. Set up a safety I/O connection of a type supported by the DUT. 
27. Invalidate the N_Run_Idle bit in the mode byte for Max_Fault_Count — 1 times 
28. Verify that the packet is dropped and connection continued. 
29. Send a data packet with an invalid N_Run_Idle bit in the mode byte one more time 
30. Verify that the connection is terminated. 
31. Set up a safety I/O connection of a type supported by the DUT. 
32. Send a data packet with an invalid rollover count in the data CRC for Max_Fault_Count 
— | times 
33. Verify that the packet is dropped and connection continued. 
34. Send a data packet with an invalid rollover count in the data CRC one more time 
35. Verify that the connection is terminated. 
TST36 - Single-Cast Consumer Communication Failure 
ee Requirement 
FRSI1 All consumers shall monitor the periodic transmission of data and go to a safety state if 
the periodic transmissions cease. 
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Requirement . 
NGOS Requirement 

FRS12 When the Safety Layer detects an error requiring connection termination the termination 

shall be implemented using the following sequence. 

The safety layer detects an error requiring termination 

The safety layer notifies the application program by setting the connection status to 
indicate a safety communications fault 

The safety application shall transition data and I/O (e.g. set outputs to the safety state) 
associated with the connection to a safety state 

The safety layer shall notify the underlying communications system of an error and 
request the termination of the connection by setting its status to indicate a safety 
communications error 

The safety layer shall not transition from its safety state until the fault is cleared and a 
connection restart sequence is initiated. 

FRS78 Link-triggered consumers shall maintain an activity timer, which is reset after receiving 
a valid expected message. 

FRS79 If a valid message has not been received before the activity timer expires, the link- 
triggered consumer shall terminate the connection (See 2-1.3.2) and go to the defined 
safety state. 

FRS81 If the age of the data is greater than the network time expectation the consumer shall 
terminate the connection (See 2-1.3.2) and go to the defined safety state. 

FRS287 For all consumed safety connections, time stamp checking shall be enabled if the mode 
of the data indicates Run. 


TST36 The Single-cast Consumer Communication Failure test shall confirm that consumer 
DUTs perform safe state behavior on communication failures. 


Required Initial Conditions: 


1. This test supports both the base format and the Extended Format. It will use the 
Timeout_Multiplier.PI enhanced definition. 


2 Run SPTE as a target 
Test Procedure: 


1. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 1 or 2 bytes. 


2. The establishment of a safety I/O connection is a positive test case for the date age and 
time stamp checking. 

35 The producer will send data with the Time Stamp value set to 0 and the Run_Idle bit set 
to IDLE 

4, The data will be sent at such a rate that the age detection limit will be exceeded. 

5. Confirm that the connection remains established. 


The producer will send data with the Time Stamp value set to 0 and the Run_Idle bit set 
to RUN 


The data will be sent at such a rate that the age detection limit will be exceeded. 


8. The consumer will detect the error and the connection will be terminated 
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F-3.9 


F-3.9.1 


Multi-Cast Connections 


This section will define tests specifically related to Multi-Cast Connections. It defines 
producer and consumer tests separately since the test setups will be unique for each. 


TST37 - Base Format Multi-Cast Consumer Negative 


Requirement 


Number Requirement 


FRS9 The following Sequence of checks shall be used to check messages: 
Ping count check 

Evaluate Time stamp section CRC 

Evaluated Time Stamps 

Evaluate Actual Data CRC 

Evaluate Complement Data CRC 

Perform Cross-Check 


FRS13 When crosschecked safety data are found to be different, the data is treated as faulty. 
The base format consumer shall terminate the connection (See Section 2-1.3.2) and the 
Extended Format consumer will increment the Consumer_Fault_Count and drop the 
packet if the count is less than the Max_Fault_Number, or terminate the connection if is 
equal to or greater than the Max_Fault_Number. 


FRS190 The Reserved bits shall be ignored by the consumer except for CRC checking and 
Actual/Complement checking of the TBD_Bit/N_TBD_Bit pair. 
FRS191 The N_TBD_Bit complement bit shall always be the complement of the TBD_Bit 


TST37 The Base Format Multi-cast Consumer test shall test all the basic features of the safety 
protocol by injecting errors in each component listed in the above requirement 


Required Initial Conditions: 
1. Run SPTE as a target 
Test Procedure: 


1. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


2. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 

3. The connection will run for a set period of time. 

4. The producer will send an incorrect Time Stamp CRC. 

33 The consumer will detect the error and the connection will be terminated. 

6. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 

hs The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 

8. The producer will send an out of sequence Time Stamp. 
The consumer will detect the error and the connection will be terminated. 


10. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 
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1. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


2. The producer will send an incorrect Data CRC. 
The consumer will detect the error and the connection will be terminated. 


4. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


5. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


6. The producer will send an incorrect Complemented Data CRC. 
7. The consumer will detect the error and the connection will be terminated. 


Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


9. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


20. The producer will send a Data and Complemented Data mismatch. 
21. The consumer will detect the error and the connection will be terminated. 


22. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


23. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


24. The producer will send a TBD_Bit and N_TBD_Bit mismatch. 
25. The consumer will detect the error and the connection will be terminated. 


TST117 - Extended Format Multi-Cast Consumer Negative 


Requirement 


Number Requirement 


FRS9 The following Sequence of checks shall be used to check messages: 
Ping count check 

Evaluate Time stamp section CRC 

Evaluated Time Stamps 

Evaluate Actual Data CRC 

Evaluate Complement Data CRC 

Perform Cross-Check 


FRS13 When crosschecked safety data are found to be different, the data is treated as faulty. 
The base format consumer shall terminate the connection and the Extended Format 
consumer will increment the Consumer_Fault_Count and drop the packet if the count is 
less than the Max_Fault_Number, or terminate the connection if is equal to or greater 
than the Max_Fault_Number. 


FRS190 The Reserved bits shall be ignored by the consumer except for CRC checking and 
Actual/Complement checking of the TBD_Bit/N_TBD_Bit pair. 

FRS191 The N_TBD_Bit complement bit shall always be the complement of the TBD_Bit 

FRS378 The active seeding of the CRC with the rollover count in Extended Format Multi-cast 


messages shall begin immediately on first production. 


TST117 The Extended Format Multi-cast Consumer test shall test all the basic features of the 
safety protocol by injecting errors in each component listed in the above requirement 
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Required Initial Conditions: 


1. 


Run SPTE as a target 


Test Procedure: 


1. 


23. 
24. 


Pus 


n 


Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


The connection will run for a set period of time. 


Read the Producer/Consumer Fault Count Attribute in Safety Validator and confirm it is 
zero. 


The producer will send an incorrect Complement Data CRC. 
The consumer will detect the error and the message will be dropped. 


Read the Producer/Consumer Fault Count Attribute in Safety Validator instance and 
confirm it is non-zero but less than Max_Fault_Count 


Repeat the production 4 more times 


The consumer will detect the error and the message will be dropped for production 2, 3, 
& 4and close the connection after the 5" production 


Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


The producer will send an out of sequence Time Stamp. 
The consumer will detect the error and the message will be dropped. 


Read the Producer/Consumer Fault Count Attribute in Safety Validator instance and 
confirm it is non-zero but less than Max_Fault_Count 


Repeat the production 4 more times 


The consumer will detect the error and the message will be dropped for production 2, 3, 
& 4and close the connection after the 5" production 


The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


The producer will send a message using an invalid Rollover count. 
The consumer will detect the error and the message will be dropped. 


Read the Producer/Consumer Fault Count Attribute in Safety Validator instance and 
confirm it is non-zero but less than Max_Fault_Count 


Repeat the production 4 more times 


The consumer will detect the error and the message will be dropped for production 2, 3, 
& 4and close the connection after the 5" production 


Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 
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25. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


26. The producer will send an incorrect Data CRC. 
27. The consumer will detect the error and the message will be dropped. 


28. Read the Producer/Consumer Fault Count Attribute in Safety Validator instance and 
confirm it is non-zero but less than Max_Fault_Count 


29. Repeat the production 4 more times 


30. The consumer will detect the error and the message will be dropped for production 2, 3, 
& 4and close the connection after the 5" production 


31. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


32. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


33. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


34. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


35. The producer will send a Data and Complemented Data mismatch. 
36. The consumer will detect the error and the message will be dropped. 


37. Read the Producer/Consumer Fault Count Attribute in Safety Validator instance and 
confirm it is non-zero but less than Max_Fault_Count 


38. Repeat the production 4 more times 


39. The consumer will detect the error and the message will be dropped for production 2, 3, 
& 4and close the connection after the 5" production 


40. Set up a safety I/O connection of a type supported by the DUT. The connection size will 
be 3 bytes or larger. 


41. The establishment of a safety I/O connection is a positive test case when the DUT is a 
consumer. 


The producer will send a TBD_Bit and N_TBD_Bit mismatch. 


The consumer will detect the error and the message will be dropped. 


ars 
YoN 


44. Read the Producer/Consumer Fault Count Attribute in Safety Validator instance and 
confirm it is non-zero but less than Max_Fault_Count 


is 
a 


Repeat the production 4 more times 


46. The consumer will detect the error and the message will be dropped for production 2, 3, 
& 4and close the connection after the 5" production 


F-3.9.2.1 TST38 - Base Format Multi-cast Consumer PID 
Requirement 
Number 


FRS7 The PID or CID is incorporated within the Safety CRC calculation in both the producer 
and the consumer, thus, if a message is mistakenly received, it shall be detected when 
the CRC is checked. 

FRS1I55 The Producer Identifier (PID) shall be used as an initial seed value in the CRCs in the 
runtime protocol. 


Requirement 
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Requirement A 
Nammbey Requirement 
FRS156 The Consumer shall obtain the Producer Identifier from the SafetyOpen and use the 
value as an initial seed in runtime checking the safety CRCs. 


TST38 The Multi-cast Consumer PID Test shall confirm that a multi-cast consumer DUT will 
include the producer ID in the CRC calculation and detect if data is received from an 
unintended source. 


Required Initial Conditions: 
1. Run SPTE as a target 
Test Procedure: 


The DUT will be configured with a representative configuration 


2: The DUT will be triggered to send SafetyOpen and an initial Producer ID will be 
returned 


3: Valid safety data will be sent and the test will confirm that the data is accepted 


4. Valid Safety data will be sent, but with an invalid Producer ID being used to seed the 
safety CRC 


5. The test will confirm that the DUT detects the invalid CRC, faults the connection, 
notifies the application, and safety states the consumed data. 


F-3.9.2.2 TST125 - Extended Format Multi-cast Consumer PID/Rollover 


Requirement 


Number Requirement 


FRS7 The PID or CID is incorporated within the Safety CRC calculation in both the producer 
and the consumer, thus, if a message is mistakenly received, it shall be detected when 
the CRC is checked. 


FRSI55 The Producer Identifier (PID) shall be used as an initial seed value in the CRCs in the 
runtime protocol. 


FRS156 The Consumer shall obtain the Producer Identifier from the SafetyOpen and use the 
value as an initial seed in runtime checking the safety CRCs. 
FRS378 The active seeding of the CRC with the rollover count in Extended Format Multi-cast 


messages shall begin immediately on first production. 


TST125 The Extended Format Multi-cast Consumer PID/Rollover Test shall confirm that a 
multi-cast consumer DUT will include the producer ID and proper rollover count in the CRC 
calculation and detect if data is received from an unintended source. 


Required Initial Conditions: 
1. Run SPTE as a target 
Test Procedure: 


The DUT will be configured with a representative configuration 


oon The DUT will be triggered to send SafetyOpen and an initial Producer ID, Initial Time 
Stamp, and Initial Rollover count will be returned 


3: Valid safety data will be sent and the test will confirm that the data is accepted 
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F-3.9.2.3 


4. Valid Safety data will be sent, but with an invalid Producer ID being used to seed the 
safety CRC for Max_Fault_Count — | times. 


Prawn 


Verify that the packet is dropped and connection continued. 
Send a data packet with an invalid Producer ID one more time 
Verify that the connection is terminated. 


Valid Safety data will be sent, but with an invalid Rollover Count being used to seed the 


safety CRC for Max_Fault_Count — | times. 


9. Verify that the packet is dropped and connection continued. 


10. | Send a data packet with an invalid Rollover Count one more time 


11. Verify that the connection is terminated 


12. The test will confirm that the DUT detects the invalid CRC, faults the connection, 
notifies the application, and safety states the consumed data. 


TST39 - Multi-cast Consumer Communication Failure Response 


Requirement 
Number 


Requirement 


FRS11 


All consumers shall monitor the periodic transmission of data and go to a safety state if 
the periodic transmissions cease. 


FRS12 


When the Safety Layer detects an error requiring connection termination the termination 
may be implemented using the following sequence. 


e — The safety layer detects an error requiring termination 


e — The safety layer notifies the application program by setting the connection status to 
indicate a safety communications error 


e — The safety application shall transition data and I/O associated with the connection 
toa safety state 

© The safety layer shall notify the underlying communications system of an error and 
request the termination of the connection by setting its status to indicate a safety 
communications error 


The safety layer shall not transition from its safety state until the fault is cleared 
and a connection restart sequence is initiated. 


FRS78 


Link-triggered consumers shall maintain an activity timer, which is reset after receiving 
a valid expected message. 


FRS79 


If a valid message has not been received before the activity timer expires, the link- 
triggered consumer shall terminate the connection and go to the defined safety state. 


FRS81 


Tf the age of the data is greater than the network time expectation the consumer shall 
terminate the connection (See 2-1.3.2) and go to the defined safety state. 


FRS287 


For all consumed safety connections, time stamp checking shall be enabled if the mode 
of the data indicates Run. 


TST39 The Multi-cast Consumer Communication Failure test shall confirm that consumer 
DUTs perform safe state behavior on communication failures. 


Required Initial Conditions: 


1. This will function for both Base and Extended Format connections 
Di Run SPTE as a target 


Test Procedure: 


1. Send a Time Correction message at the appropriate time 
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F-3.9.2.4 


2. Generate a safety message with a Time Stamp that exceeds the age limit based on 
configured timeout parameters 


3. Confirm that the DUT faults the connection and stops responding to Ping Requests and 
begins requesting a new connection 


4. Allow the DUT to re-establish the connection 


5: Break communication with the device 

6. Allow the DUT to re-establish the connection 

Ts Don’t send a Time Correction Message 

8. Confirm that the DUT faults the connection and stops responding to Ping Requests and 


begins requesting a new connection 
9. Allow the DUT to re-establish the connection 
10. Produce data with Run_Idle = Run, but at an EPI rate that violates the age limit 


11. Confirm the DUT detects the age violation and faults the connection 


TST40 - Base Format Multi-cast Consumer Time Correction Negative 


Requirement . 
Number Requirement 

FRS62 Parity_Even in the Time Correction message shall be the even parity of bits 0 through 6 
of the Message 

FRS92 For DeviceNet Multi-cast connections, a separate message shall be used to communicate 
time correction information form the produce to each multi-cast consumer. 

FRS107 The consumer shall remain in a safety state until the initial ping sequence is successfully 
completed. 

FRS206 The Multi_Cast_Active_Idle, and the Consumer_Time_Correction_Value shall be applied 
by the consumer indicated by the Consumer_#. 

FRS209 The Multi_Cast_Active_Idle bit value of 0 shall indicate Idle, and the 
Multi_Cast_Active_Idle bit value of | shall indicate Active. 

FRS211 Tf the consumer sees the Multi-Cast_Active_Idle bit transition from Active to Idle, it shall 
close the connection if the base format is used. If the Extended Format is used and the 
Max_Fault_Count has not been reached, the packet will be dropped, otherwise the 
connection will be closed. 

FRS216 The Reserved bits shall be ignored by the consumer except for CRC checking and 
MC_Byte_2 checking 

FRS305 If the Time_Correction_Ping_Interval_Count is greater than the Timeout_Multiplier.PI + 
1, the connection shall be faulted. 
This requirement is confirmed indirectly 

FRS374 For the Base Format, Timeout_Multiplier.PI shall be equal to the Timeout_Multiplier. 
For the HiAvailabilityFormat, Timeout_Multiplier.PI shall be equal to the smaller of 
Timeout_Multiplier or 4, whichever is lower. 


TST40 The Base Format Multi-cast Consumer Time Correction Processing Test shall confirm 
that the Multi-cast Consumer DUT is processing the Time Correction Message properly. 


Required Initial Conditions: 
1. Run SPTE as an originating target 
Test Procedure: 


1. Issue a ping request 
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B08 AON 


Process the Time Coordination response and construct a EF or Base format Time 
Correction message 


Send a valid Time correction message with Multi_Cast_Active_Idle = Active = 1 


Confirm that the multi-cast consumer DUT establishes the safety connection and applies 
the data 


Send additional time correction message with Consumer # other than that of the DUT 
with Multi_Cast_Active_Idle =IDLE 


Confirm the multi-cast consumer DUT ignores these messages 
Start another ping cycle 

Inject an invalid Parity-bit in the Time Correction message 
Confirm that the multi-cast consumer DUT faults the connection. 
Allow the multi-cast consumer DUT to re-establish the connection 


During this ping cycle, send a Time Correction message with non-zero reserved bits 
(with valid CRC and MC_Byte_2) 


Confirm the multi-cast consumer DUT accepts this time correction as valid 


Complete a valid ping cycle including a valid Time Correction with 
Multi_Cast_Active_Idle = Active (1) 


During the next ping cycle send a valid Time correction message with 
Multi_Cast_Active_Idle = Idle (0) 


Confirm the multi-cast consumer DUT faults the connection 
Allow the multi-cast consumer DUT to re-establish the connection 
Complete a valid ping cycle to fully establish the connection 


Stop sending Time Correction messages to the DUT but continue sending data and ping 
requests normally 


Confirm the multi-cast consumer DUT faults the connection after Timeout_Multiplier.PI 
+1 Ping Intervals 


TST126 — Extended Format Multi-cast Consumer Time Correction Negative 


Requirement . 
NGHESS Requirement 

FRS62 Parity_Even in the Time Correction message shall be the even parity of bits 0 through 6 
of the Message 

FRS92 For DeviceNet Multi-cast connections, a separate message shall be used to communicate 
time correction information form the produce to each multi-cast consumer. 

FRS107 The consumer shall remain in a safety state until the initial ping sequence is successfully 
completed. 

FRS206 The Multi_Cast_Active_Idle, and the Consumer_Time_Correction_Value shall be applied 
by the consumer indicated by the Consumer_#. 

FRS209 The Multi_Cast_Active_Idle bit value of 0 shall indicate Idle, and the 
Multi_Cast_Active_Idle bit value of | shall indicate Active. 

FRS211 Tf the consumer sees the Multi-Cast_Active_Idle bit transition from Active to Idle, it shall 
close the connection if the base format is used. If the Extended Format is used and the 
Max_Fault_Count has not been reached, the packet will be dropped, otherwise the 
connection will be closed. 

FRS216 The Reserved bits shall be ignored by the consumer except for CRC checking and 
MC_Byte_2 checking 
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Requirement 


Number Requirement 


FRS305 If the Time_Correction_Ping_Interval_Count is greater than the Timeout_Multiplier.PI + 
1, the connection shall be faulted. 


This requirement is confirmed indirectly 
FRS374 For the Base Format, Timeout_Multiplier.PI shall be equal to the Timeout_Multiplier. 


For the HiAvailabilityFormat, Timeout_Multiplier.PI shall be equal to the smaller of 
Timeout_Multiplier or 4, whichever is lower. 


TST126 The Extended Format Multi-cast Consumer Time Correction Processing Test shall 
confirm that the Multi-cast Consumer DUT is processing the Time Correction Message 
properly. 


Required Initial Conditions: 
1. Run SPTE as an originating target 
Test Procedure: 


Ls Issue a ping request 


2. Process the Time Coordination response and construct a Extended Format Time 
Correction message 

3. Send a valid Time correction message with Multi_Cast_Active_Idle = Active = 1 

4, Confirm that the multi-cast consumer DUT establishes the safety connection and applies 
the data 

5. Send additional time correction message with Consumer # other than that of the DUT 


with Multi_Cast_Active_Idle =IDLE 
Confirm the multi-cast consumer DUT ignores these messages 
Start another ping cycle 


Send Time Correction packets with an invalid Parity-bit for (Max_Fault_Count) or 
(Timeout_Multiplier.PI+1 Ping Intervals); whichever is less. 


9. Verify that the DUT closes the connection after the last transmission but not the prior 
ones. 


0. Allow the multi-cast consumer DUT to re-establish the connection 


11. During this ping cycle, send a Time Correction message with non-zero reserved bits 
(with valid CRC) 


2. Confirm the multi-cast consumer DUT accepts this time correction as valid 


3. Complete a valid ping cycle including a valid Time Correction with 
Multi_Cast_Active_Idle = Active (1) 


4. During the next ping cycle send a valid Time correction message with 
Multi_Cast_Active_Idle = Idle (0) for (Max_Fault_Count) or (Timeout_Multiplier.PI+1 
Ping Intervals); whichever is less. 


5. Confirm the multi-cast consumer DUT faults the connection after the last transmission 
but not the prior ones. 


Allow the multi-cast consumer DUT to re-establish the connection 


Complete a valid ping cycle to fully establish the connection 
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18. Stop sending Time Correction messages to the DUT but continue sending data and ping 
requests normal 


19. Confirm the multi-cast consumer DUT faults the connection after Timeout_Multiplier.PI 
+1 Ping Intervals 


F-3.9.2.6 TST41 - Multi-cast Producer Time Correction Generation Negative 


Requirement A 
Nahas Requirement 

FRS65 The Consumer_# in the Time Correction message shall indicates the number of the 
consumer that this message is directed to. 

FRS179 The Run_Idle bit value of 0 shall indicate Idle, and the Run_Idle bit value of 1 shall 
indicate Run 

FRS205 For multi-cast produced data the Multi_Cast_Active_Idle, and 
Consumer_Time_Correction_Value shall be directed to the consumer indicated by the 
Consumer_# field of the message. 

FRS209 The Multi_Cast_Active_Idle bit value of 0 shall indicate Idle, and the 
Multi_Cast_Active_Idle bit value of 1 shall indicate Active. 

FRS210 Once the Multi_Cast_Active_Idle bit has been set to Active after 1st data production, this 
bit shall not be set back to idle until the safety connection is re-initialized 

FRS358 Multi_Cast_Active_Idle in the Time Correction message shall indicate Idle if transmitted 
before this consumer has responded with a valid time coordination message 


TST41 The Multi-cast Producer Time Correction Generation Test shall generate a number of 
conditions to show the producer is generating the Time Correction message correctly. 
Initial Conditions: 


1. This test supports both the base format and the Extended Format. It will use the 
Timeout_Multiplier.PI enhanced definition. 


2: Run the SPTE as an originator of either the EF or Base format connections 


Procedure: 

1. Note the assigned Producer Id 

2% Confirm a Ping request is generated at the assigned consumer # 

3s Send the appropriate Time Coordination responses at the appropriate time 


Run TST18 - Producer Time Correction CRC 


Confirm that the Time Correction messages has Multi_Cast_ Run_Idle is “Run (=1)” 


ON GON ge 


Run TST19 - Producer Time Correction Mcast Byte & Mcast Byte 2 if the Base format 
is used or TST 111 if the Extended Format is used. 


Confirm the Consumer # matches the number assigned to the tester 


= 


On the next ping response, generate a EF or Base format Time Coordination message 
with a bad CRC 


9. Confirm the Time Correction messages are no longer sent 
10.  Re-establish the connection 
11. After one good ping cycle, send a Time Coordination response with a bad Ack_Byte 


12. Confirm the Time Correction messages are no longer sent 
13. Re-establish the connection 
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F-3.10 
F-3.10.1 


F-3.10.1.1 


F-3.10.1.2 


14. After one good ping cycle, stop sending Time Coordination responses 

15. Confirm the Time Correction messages are no longer sent 

16. if some Time Correction message get through before detection, confirm the 
Multi_Cast_Active_Idle = Active = 1 

Device Configuration 


Target Configuration 


The DUT in this section will be a target (receiver) of connection requests. The requirements 
called out here will determine if the server is properly handling the Type 1 
Safety_Forward_Open message over a Class 3 connection. 


There are some tests that must be done regardless of the types of connections supported. 
However, these tests will need to be executed as part of the connection tests for a supported 
type. Therefore the tests defined here should be considered generic and must be adapted to 
work as part of the test suite for the supported connection types. 

Configuration Ownership 


These tests will verify all Server behavior associated with connection ownership. 


TST42 - Configuration UNID 


Requirement 7 
Wamben Requirement 
FRS165 Any attempts to reconfigure a device via the SafetyOpen shall be rejected if the tool only 
configuration mode is selected. 
SRS70 The Configuration OUNID attribute shall have the following special meanings assigned; 


0 = No owner, accept any 
all OxFF = Software Tool is the assigned owner 


SRS205 When the Configuration UNID attribute is set to “No owner, accept any”, CIP Safety 
Devices shall capture the first configuration source (Type | and/or Configure_Request) 
as the owner. 


TST42 The Configuration UNID test shall confirm that the server DUT will behave properly 
with the various OUNID values. 


Initial Conditions: 

Ls, This test supports both the base format and the Extended Format. The Extended Format 
will use the EF Safety Segment type 

2 Run the SPTE as an originator of either the EF or Base format connections 

The test should do the following: 

1. Reset the DUT to an out-of-box condition (the device should initialize the Config. UNID 
to 0, accept any) 
Open a class 3 connection 
Set the TUNID to get the device into Configure mode 


4. If the DUT support configuration via Type 1 connection requests, send a Type 1 w/valid 
configuration using any OUNID 
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Fe SO 00: ST Oy Ui 


Confirm the DUT accepts the configuration and connects 

Reset the DUT back to out-of-box condition and set the TUNID 
Send a Configure_Request with a OUNID = OxFF. 

Complete the configuration with a valid configuration. 

Open a Class 3 connection 


0. Send the DUT a completely valid Type 1 SafetyOpen to an input or output assembly 


with any convenient OUNID 


11. confirm that the target responds with the error code 0x01, 0x105 “Ownership conflict or 
OUNID mismatch ” 


12. Send the DUT a completely valid Type 1 SafetyOpen with OUNID=all OxFFs 


13. confirm that the target responds with the error code 0x01, 03 “Configuration not allowed 
(configuration locked)” 


F-3.10.1.3 || TST43 - Input Type 1 Connection Establishment 


Requirement 
Number 


Requirement 


FRS100 


It shall be permissible to combine the device and the connection configuration. 


FRS167 


The OUNID of the originating device shall be stored in non-volatile storage with the 
configuration to which it is associated. 


FRS164 


If the TUNID to UNID comparison is successful than the SafetyOpen destination is 
deemed to be correct and processing shall continue. 


SRS4 


Safety Devices shall NV-store the OUNID for the configuration 


SRS7 


The originator of a Type | SafetyOpen that configures a previously unconfigured & 
unowned input device shall become the owner of the configuration. 


SRS11 


A target input device that has an existing configuration shall (at a minimum) do the 
following when a type 1 Safety Open is received: 


Verify the CPCRC over the connection parameters is correct, 
Verify that the TUNID in the SafetyOpen matches the device TUNID 
Verify the Electronic Key matches the device 


If configuration data is included (type 1), verify that the OUNID in the SafetyOpen 
matches the stored OUNID 


Calculate the SCCRC over the received data and confirm that it obtains the same value 
Verify and validate the connection parameters, 

Validate the application path 

Confirm the safety connection requested is supported 

Safety parameters are within valid ranges 


Start the reconfiguration process (enter Config State), close and inhibit connections 
during the reconfiguration (respond to connection requests with an error response, 
“Invalid Mode/State”), 


Update the configuration and SCID in NV Memory, 
Transition the connection to the established state, and the device to the executing state. 
New connections can now be accepted 


SRS171 


When a device receives a type | SafetyOpen containing configuration data and an 
SCID that matches its existing configuration, it shall re-apply the configuration. All 
existing rules checks (i.e. OUNID and TUNID checks) shall still apply. 


SRS173 


Targets shall respond to a Type 2 SafetyOpen with an error code 0x01, additional code 
0x0110 (device not configured), when the device is not configured. 
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TST43 The Configuration Ownership Retention test shall verify that the server DUT performs 
all the basic tests and steps when processing a Type | safety open. 


Initial Conditions: 

1. This test supports both the base format and the Extended Format. The Extended Format 
will use the EF Safety Segment type 

2. Run the SPTE as an originator of either the EF or Base format connections 


This test will be performed as follows: 

Preset the DUT to an out-of-box condition and set the TUNID 

Send a Type 2b SafetyOpen (null SCID). 

Confirm the DUT sends an error 0x01, 0x110 to indicate it needs to be configured. 


Send a Type 1 SafetyOpen with valid configuration, SCID, TUNID and preset OUNID 
(this should establish ownership in the device) 


Peet aa 


Power cycle the device 
Re-send the SafetyOpen with the same configuration, but with incorrect TUNID 
Confirm the DUT responds with error 01 03, TUNID mismatch 

Re-send the SafetyOpen with the same configuration, but with another OUNID 
Confirm the DUT responds with error 01 105, CFUNID mismatch 


0. Re-send the SafetyOpen with the same configuration, valid TUNID, OUNID, but with an 
invalid SCCRC 


Confirm the DUT responds with error 01 x80C, SCID mismatch 


2. Re-send the SafetyOpen with the same configuration, valid TUNID, OUNID, SCID, and 
CPCRC with a bad connection path 


eo PMPrAnAM 


3. Confirm the DUT responds with error 01 117, Connection Path Error 

4. Re-send the SafetyOpen with NEW configuration and SCID, but the base OUNID. 

5. Confirm that the SafetyOpen is accepted and the DUT adopts the new configuration. 

6. Confirm the safety I/O connection gets established 

F-3.10.1.4 || TST44 - Output Type 1 Connection Establishment 
Requirement A 
Number Requirement 

FRS100 It shall be permissible to combine the device and the connection configuration. 

FRS164 If the TUNID to UNID comparison is successful than the SafetyOpen destination is 
deemed to be correct and processing shall continue. 

FRS168 Outputs device: II store the OUNID associated with safety outputs to prevent other 
originators from hijacking outputs inadvertently. 

SRS6 Output devices shall NV-store the OUNID associated with the safety output connection. 

SRS8 A Type | SafetyOpen that configures a previously unconfigured & unowned output 
device shall become the owner of both the connection and the configuration 

SRSO Ifa Type 1 SafetyOpen is sent where the originator OUNID is different than the OUNID 
that is stored with the connection the SafetyOpen shall be rejected and an error message, 
“O_UNID Mismatch” is returned 

SRS12 A target output device that has an existing configuration shall (at a minimum) do the 
following when a type 1 Safety Open is received. 
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Requirement A 
Naber! Requirement 

Verify the CPCRC over the configuration is correct, 
Verify that the TUNID in the SafetyOpen matches the device TUNID 
Verify the Electronic Key matches the device 
If configuration data is included (type 1), verify that the OUNID in the SafetyOpen 
matches the stored OUNID for the configuration 
If the connection path is to an output resource, verifies that the OUNID in the 
SafetyOpen matches the OUNID for the connection, 
Calculate the SCCRC over the received data and confirm that it obtains the same value 
Verify and validate the connection parameters, 
Validate the application path 
Confirm the safety connection requested is supported 
Safety parameters are within valid ranges 
Start the reconfiguration process by closing and inhibiting connections during the 
reconfiguration (respond to connection requests with an error response, “Invalid 
Mode/State”), 
Update the configuration and SCID in NV memory, 
Transition the connection to the established state, and the device to the executing state. 
New connections can now be accepted 

SRS135 The Output Connection Owner attribute shall be supported for all safety output 
assemblies. 

SRS173 Targets shall respond to a Type 2 SafetyOpen with an error code 0x01, additional code 
0x0110 (device not configured), when the device is not configured. 


TST44 The Output Type 1 Connection Establishment test shall verify that server DUT with 
safety outputs performs all the basic tests and steps when processing a Type | safety open. 


Initial Conditions: 
Lb. This test supports both the base format and the Extended Format. The Extended Format 


will use the EF Safety Segment type 


2. Run the SPTE as an originator of either the EF or Base format connections 
This test will be performed as follows: 

Preset the DUT to an out-of-box condition and set the TUNID 

Send a Type 2b SafetyOpen (null SCID). 


Confirm the DUT sends an error 0x01, 0x110 to indicate it needs to be configured. 


Send a Type | SafetyOpen with valid configuration, SCID, TUNID and preset OUNID 
(this should establish ownership in the device) 


rb 


- 


Power cycle the device 

Re-send the SafetyOpen with the same configuration, but with incorrect TUNID 
Confirm the DUT responds with error 01 03, TUNID mismatch 

Re-send the SafetyOpen with the same configuration, but with another OUNID 
Confirm the DUT responds with error 01 105, CFUNID mismatch 


0. Re-send the SafetyOpen with the same configuration, valid TUNID, OUNID, but with an 
invalid SCCRC 


eS MOF, SP ON IN 


-F-75- 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Appendix F: Safety Test Plan 


Confirm the DUT responds with error 01 x80C, SCID mismatch 


2. Re-send the SafetyOpen with the same configuration, valid TUNID, OUNID, SCID, and 
CPCRC with a bad connection path path 


Confirm the DUT responds with error 01 117, Connection Path Error 

Re-send the SafetyOpen with NEW configuration and SCID, but the original OUNID 
Confirm that the SafetyOpen is accepted and the DUT adopts the new configuration. 
Confirm the safety I/O connection gets established 


Send a Type 2b SafetyOpen (null SCID) with a different OUNID to the same output 
assembly 


8. Confirm the DUT sends an error 0x01, 0x 106 to indicate OUNID mismatch 


Vary the OUNID used in step 6 by changing MAC ID/IP Address and/or SNN to make sure 
there is no sensitivity to either. 


cGy Gree 32 


F-3.10.2 Originators 
F-3.10.2.1 Originators Configuring Targets 


The DUT in this section will be an originator (sender) of connection requests. The tests called 
out here will determine if the client is properly issuing the Type 1 Safety Open message. 


These tests will be highly dependent upon the capabilities and configuration of the client 
device. For example, not all clients will support configuring a device as part of connection 
establishment. The client device may also need to be re-configured a number of times to verify 
all the behavior. The tests should be written in such a way as to allow for developers/testers 
to isolate or select the test functions that apply to the product’s capabilities. 
F-3.10.2.1.1__ TST45 - Type 1 Configuration from Originators 
Ee Requirement 

FRS108 If a device either responds to a Type 2 SafetyOpen with a SCID mis-match or requests a 
download because it is being replaced, the following sequence shall be followed. 
The originator sends a Type 2 SafetyOpen to the target device 
The target responds with a mode state error 
The originator calls the Safety Application to perform a download 
The Safety Application performs and verifies the download. 

The download may be a series of commands to the device or 

The download may be a Type 1 SafetyOpen. 

The originator repeats the Type 2 SafetyOpen to establish the connection verify the 
configuration. 

FRS110 The Safety Configuration Data CRC (SCCRC) shall only be calculated over the application 
data that is stored in the device. Any headers or sizes included in the SafetyOpen shall be 
excluded. 

FRS158 The SCCRC itself shall be included in the calculation of the CRCRC 

FRS160 The SCTS parameter in the Safety Open shall be included in the calculation of the CPCRC. 

FRS172 On DeviceNet, the originator shall establish an explicit messaging connection with the 
router or end-node to deliver the Forward_Open or SafetyOpen service requests. 

FRS170 DeviceNet originators shall use the Connection Object’s Safety Open request for local 
targets 

SRS172 If a connection has configuration data, this configuration data shall only be sent when it is 
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Requirement A 
NaabeS Requirement 

needed. Unless the configuration has been changed, this shall be accomplished by sending 
a Type 2 SafetyOpen, and only followed with a Type | SafetyOpen if the target responds 
with Device Not Configured error. 

SRS174 When an originator detects that the configuration data held for a device has changed, it shall 
always issue a type 1 connection request the first time it connects. The SCID returned shall 
be validated against the value held. 


2: 


ly 


20. 
21. 


ee errr 


[ST45 The Type | Configuration Process Test shall confirm a number of requirements 
required with Type 1 SafetyOpens. 


Initial Conditions: 


This test supports both the base format and the Extended Format. The Extended Format 
will use the EF Safety Segment type 


Run the SPTE as an originator of either the EF or Base format connections 


Che following procedure will be used to test an originator DUT type 1 configuration process. 
This test will be a local subnet test: 


Configure the originator DUT with a device configuration file and representative 
connection parameter set 


Activate the DUT so it attempts to establish a connection 

Confirm the DUT establishes an explicit connection 

Confirm the first connection attempt is a Type 1 or a Type 2a connection. 
Type | connection attempt: 

Check the configuration and calculate the SCCRC over the data. 
Confirm it matches the value sent. 


Send a success reply with SCID and confirm the DUT and software recognize successful 
initial download. 


Close all connections and power cycle the DUT. 

Type 2a connection attempt: 

Send a negative reply with SCID mismatch error code 

Confirm the connection attempt is a Type 1 connection. 

Check the configuration and calculate the SCCRC over the data. 
Confirm it matches the value sent. 


Send a success reply with SCID and confirm the DUT and software recognize the 
successful initial download. 


Close all connections. 
Confirm the connection attempt is a Type 2a connection. 


Send a negative reply with SCID mismatch error code 


Confirm the connection attempt is a Type 1 connection: 


Check the configuration and calculate the SCCRC over the data. 
Confirm it matches the value sent. 
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22. Senda success reply with SCID and confirm the DUT and software recognize the 
successful initial download. 


23. Close all connections 

24. Confirm the connection attempt is a Type 2a connection. 

25. Send a negative reply with SCID mismatch error code 

26. Confirm the connection attempt is a Type | connection. 

27. Check the configuration and calculate the SCCRC over the data. 
28. Confirm it matches the value sent. 


29. Send a success reply with SCID and confirm the DUT and software recognize the 
successful initial download. 


30. Close all connections 
F-3.10.2.2 Connection Configuration Object Tests 
F-3.10.2.2.1_ TST105 - Connection Enable/Disable Test 


Requirement fi 
Nauk Requirement 
FRS334 The SafetyClose Service shall be used to close connections with a Safety Targets (and in 
the case of a FowardClose all other nodes in the connection path). 
FRS339 When a SafetyClose success reply is received, the originator and each intermediate node 


along the path, closes the connection and releases resources associated with that connection. 
But the originator shall also close the connection if no response is received within a vendor 
selected wait period 

FRS356 When the Connection Enable/Disable attribute in the CCO object is TRUE, the connection 
shall remain disabled through power cycles. When the Connection Disable attribute in the 
CCO object is FALSE, the connection shall remain enabled through power cycles. 


FRS357 Safety Devices shall support the open, close and stop services. . These services shall only 
be accepted when the device is unlocked. If the device is locked, it shall respond with a 
“Device state conflict” error. 


TST105 The Connection Enable/Disable Test shall confirm that the originator DUT maintains 
the Disabled state through power cycles and the SafetyClose Service closes connections. 


Initial conditions: 


1. Commission the DUT with a configuration which has 1 single-cast connection to an I/O 
device. DUT is initially Unlocked 
2. Prompt tester for CCO instance which contains the connection information 


The following procedure will be followed for this test: 


Allow the DUT to establish those I/O connections 

Open a Class 3 connection to the DUT 

Send a Close Connection service to CCO class, instance (provided by tester) 
Confirm DUT sends a Safety Close service 

Power cycle the DUT 

Allow the DUT to establish I/O Connections 

Confirm DUT does not issue a SafetyOpen to the configured I/O connection 


ai arn ala 


OO al ON 


Open a Class 3 connection to the DUT 
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F-3.11 


F-3.11.1 


9. Send an Open Connection service to CCO class, instance (provided by tester) 
0. Confirm DUT sends a SafetyOpen service 
1. Send a Stop Connection service to CCO class, instance (provided by tester) 
12. Confirm DUT stops producing data on the connection 
3. Power cycle the DUT 
4. Allow the DUT to establish I/O Connections 
5. Confirm DUT does not issue a SafetyOpen to the configured I/O connection 
6. Send an Open Connection service to CCO class, instance (provided by tester) 
7. Confirm DUT sends a SafetyOpen service 
8. Allow the DUT to establish I/O Connections 
9. Send a Close Connection service to CCO class, instance (provided by tester) 
20. Confirm DUT sends a Safety Close service 
21. Do not send the Safety Close Response 
22. Confirm that the DUT shuts down the connection anyway. 
23. Open a Class 3 connection to the DUT 
24. Send a Lock service to the DUT Safety Supervisor 
25. Confirm the DUT sends a success response 
26. Send a Close Connection service to CCO class, instance (provided by tester) 
27. Confirm DUT sends a “Device State Conflict” error response 


28. Send an Open Connection service to CCO class, instance (provided by tester) 
29. Confirm DUT sends a “Device State Conflict” error response 
30. Send a Stop Connection service to CCO class, instance (provided by tester) 


31. Confirm DUT “Device State Conflict” error response 
SNCT Interface Tests 


The SNCT Interface tests will be a suite of tests covering the objects and behaviors associated 
with the SNCT interface defined by the System Spec. These tests of course only apply to those 
device which implement this interface. 


TST48 - Identity Object Tests 


Requirement 5 
Number Requirement 
SRS61 The Identity Object Reset service shall not be supported in safety devices (reply to any 


requests with “Service Not Supported” error). The service shall be replaced by the Reset 
service defined by the Safety Supervisor. 


TST48 The Identity Object Tests for safety devices shall confirm that the device has 
implemented the required behavior changes to the Identity object. 


The following procedure will be rolled into the standard Identity object test: 


1. Open a Class 3 connection with the DUT 


2. Issue a proper Reset command to the Identity object 

3. Confirm the DUT rejects the message and returns “Service Not Supported” error. 
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F-3.11.2. TST50-Macld, SNN, and UNID Behavior Tests 


Requirement 5 
Naniber Requirement 

SRS106 The MACID attribute (if supported) in the DeviceNet object or the IP attribute in the 
TCPI/IP object shall always reflect the value in use. 

SRS107 The Target UNID attribute in the Safety Supervisor shall always reflect either the default or 
the current Target UNID saved through the UNID setting process. 

SRS119 If the UNID represents a valid Number (not equal to out-of-box), this number shall be 
compared to the MACID or IP Address. In case of a match the device continues its startup 
procedure. In case of a mismatch the Device transits to Abort. 

SRS120 When a device faults from a Switch-NVS setting mismatch, it shall allow either a reset to 


out-of-box, or a Recover request issued to the Safety Supervisor to clear the Abort. In both 
cases, the device shall move to the “Waiting for TUNID” state. 


FRS350. Safety devices shall monitor and detect changes in the MACID or IP address and Baud Rate 
(if applicable) switch settings 


FRS351 When a MacID switch setting change is detected, the device shall update the 
MACID_Switch_Value attribute. If the Mac ID switch equals the Mac ID in use or the Mac 
ID Switches are greater than 63 and software settable clear the Mac ID changed attribute and 
make no change in the state of the device, otherwise set the Mac ID changed attribute and 
transition to the ABORT state. 


FRS352 If a CIP safety device supports the Set_attribute service to the Macld attribute, and the 
Macld switches are set to enable the set service, Safety devices shall only accept the 
Set_Attribute while in the “Waiting for TUNID” state. Otherwise, it shall reply with a 
“Device State Conflict”. 


FRS353 If a CIP safety device supports the Set_attribute service to the Baud Rate attribute, Safety 
devices shall only accept the Set_Attribute while in the “Waiting for TUNID” state. 
Otherwise, it shall reply with a “Device State Conflict”. 


FRS354 When a Baud Rate switch setting change is detected, the device shall update the 
Baud_Rate_Switch_Changed attribute and the Baud_Rate_Switch_Value attribute, then 
transition to ABORT. 


TST50 The Macld, SNN, UNID and Switch Behavior Test shall confirm that devices behave as 
required with or without switches. 


1. DUT is reset to out-of-box condition 
The following procedure will be followed for this test: 


Set switches or Macld attribute to known value 
Confirm that the Safety Supervisor TUNID value is default value all OxFF. 
Execute Propose/Apply to set TUNID 


Covet 2 


4. Reset DUT to simulate power cycle to confirm the DUT powers up without fault and 
will accept a configuration (SRS106) 


5: Change Macld to different value (switches or Macld attribute) if Macld attribute is set, 
error Device State Conflict is returned (FRS352) 


6. Confirm that the Safety Supervisor TUNID value is the same as in the Apply TUNID. 
(SRS107) 


7. Change BaudRate to different value (switches or BaudRate attribute) if BaudRate 
attribute is set, error Device State Conflict is returned (FRS353) 


Reset DUT to simulate power cycle 
Confirm DUT enters Abort, if Macld attribute is set, state = Idle (SRS119) 
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0. Send DUT Reset to out-of-box (using original Tunid in reset request) 
1. re-establish connection 

2. Confirm that Tunid = default (all Oxff) 

3. Confirm DUT responds with Waiting for TUNID 

4. Set switches to starting value (if soft set, no change occurred) 

5 


If Macld is switch set, change Macld to different value (NO power cycle, remain ON- 
LINE) 


6. Confirm state = Abort (FRS350) (FRS351) 


7. If Macld is switch set, confirm that MacId Switch Changed Attribute = True and MacId 
Switch Value Atttribute = switch value. (FRS350) (FRS351) 


Change Macld to previous value (NO power cycle, remain ON-LINE) 


9. If Macld is switch set, confirm that MacId Switch Changed Attribute = False and Macld 
Switch Value Atttribute = switch value = MAclId. (FRS350) (FRS351) 


20. If BaudRate is switch set, (do steps 21 through 28, else skip to 29) 

21. DUT is reset to out-of-box condition 

22. Execute Propose/Apply to set TUNID 

23. Change BaudRate to different value (NO power cycle, remain ON-LINE) 
24. Confirm state = Abort (FRS350) (FRS354) 


25. If Baud Rate is switch set, confirm that Buad Rate Switch Changed Attribute = True and 
Baud Rate Switch Value Atttribute = switch value. (FRS350) (FRS354) 


26. Change BaudRate to previous value (NO power cycle, remain ON-LINE 


27. If Baud Rate is switch set, confirm that Baud Rate Switch Changed Attribute = False and 
Baud Rate Switch Value Atttribute = switch value = Baud Rate. (FRS350) (FRS354) 


28. Reset to out-of-box (using actual Tunid in reset request) (SRS120) 


29. If Baud Rate is software set, (do steps 30 through 35, else skip to 37) 
30. DUT is reset to out-of-box condition 
31. | Execute Propose/Apply to set TUNID 


32. Set BaudRate to different value, confirm device response Device_State_Conflict 
(FRS353) 


33. Confirm that Safety Supervisor state = Configuring 


34. Reset to out-of-box condition (using actual Tunid in reset request) (SRS120) 
35. Reset to out-of-box (using default Tunid in reset request) (SRS120) 

36. Confirm DUT responds with Waiting for TUNID 

37. Confirm that Tunid = default (all Oxff) 

38. Configure the DUT 


F-3.11.3 TST108- IP address switches, SNN, and UNID Behavior 


aeons Requirement 
SRS107 The Target UNID attribute in the Safety Supervisor shall always reflect either the default or 
the current Target UNID saved through the UNID setting process. 
SRS119 If the UNID represents a valid Number (not equal to out-of-box), this number shall be 
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Requirement 
Number 


Requirement 


compared to the MAC ID or IP Address. In case of a match the device continues its startup 
procedure. In case of a mismatch the Device transits to Abort. 


SRS120 When a device faults from a Switch-NVS setting mismatch, it shall allow either a reset to 


out-of-box, or a Recover request issued to the Safety Supervisor to clear the Abort. In both 
cases, the device shall move to the “Waiting for TUNID” state. 


FRS350 Safety devices shall monitor and detect changes in the MACID or the IP Attribute and Baud 


Rate (if applicable) switch settings 


FRS352 If a CIP safety device supports the Set_attribute service to the MACID or IP address 


attribute, and the MACID or IP address switches are set to enable the set service, Safety 
devices shall only accept the Set_Attribute while in the “Waiting for TUNID” state. 
Otherwise, it shall reply with a “Device State Conflict”. 


FRS364 When an IP switch setting change is detected it shall determine if the change creates a 


mismatch condition. If the IP switch differs from the IP Address attribute, it shall transition 
to the ABORT state. 


NOS AGO GN ON 


TST108 The IP address, SNN, UNID and Switch Behavior Test shall confirm that devices 
behave as required with or without switches. 


DUT is reset to out-of-box condition 


The following procedure will be followed for this test: 


Set switches or Macld attribute to known value 
Confirm that the Safety Supervisor TUNID value is default value all OxFF. 
Execute Propose/Apply to set TUNID 


Reset DUT to simulate power cycle to confirm the DUT powers up without fault and 
will accept a configuration (SRS106) 


Change Macld to different value (switches or Macld attribute) if Macld attribute is set, 
error Device State Conflict is returned (FRS352) 


Reset DUT to simulate power cycle 
Confirm DUT enters Abort. If Macld attribute is set, confirm state = Idle (SRS119) 


Confirm that the Safety Supervisor TUNID value is the same as in the Apply TUNID 
(SRS107) 


Send DUT Reset to out-of-box (using original Tunid in reset request) 
Re-establish connection 

Confirm that Tunid = default (all Oxff) 

Confirm DUT responds with Waiting for TUNID 

Set switches to starting value (if soft set, no change occurred) 


Tf Macld is switch set, change Macld to different value (NO power cycle, remain ON- 
LINE) 


Confirm state = Abort (FRS350) (FRS351) 

Change Macld to previous value (NO power cycle, remain ON-LINE) 
Reset to out-of-box (using default Tunid in reset request) (SRS 120) 
Confirm DUT responds with Waiting for TUNID 

Confirm that Tunid = default (all Oxff) 
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F-3.11.4 


F-3.11.5 
F-3.11.5.1 


F-3.11.5.2 


20. Configure the DUT 
TSTS1 - Reset Switch Test 


Requirement - 
NaibEn Requirement 
SRS126 If a reset switch is provided on a safety device, the safety device shall execute a Safety 
Supervisor Type 2 reset (i.e. reset to out-of-box, but preserve the password). 
SRS129 To clear an existing OUNID, safety targets shall support a “reset to out-of-box” using a reset 
switch on the device or using the special reset command defined in the Safety Supervisor. 


TSTS51 The Reset Switch test shall confirm that the type of reset performed is the equivalent of 
the Safety Supervisor Type 2 reset . 


The following procedure will be followed for this test: 


Ls Open Explicit Message Connection. 
2, Request a Get_Attribute_Single, Safety_Supervisor, State. 


Pass: Success_Response, state = ?, IDLE or EXECUTING 


3. Take operator intervention to activate the Safety Reset Switch. 
4. Open Explicit Message Connection. 
5. Request a Get_Attribute_Single, Safety_Supervisor, State. 


Pass: Success_Response, state = 8, waiting for TUNID. 

6. Request a Get_Attribute_Single, Safety_Supervisor, Output Connection Owner. 
Pass: Success_Response, OUNID = 0. 

he Request a Safety_Reset, type = 0, with old Password. 


Pass: Success_Response 


Safety Supervisor Functions 
TST104 - Baseline Supervisor Test 


Requirement Fi 
Naiiber : Requirement : 
SRS65 All safety devices on a CIP safety network shall support the baseline Safety Supervisor 
definition. 


TST104 The Baseline Supervisor Test shall confirm that the device implements all attributes 
and services marked “required” in the Safety Supervisor object definition. 


TBD 
TSTS2 - Propose/Apply TUNID and Reset Command Tests 
Requirement A 
Namiben Requirement 

SRS15 If the device has a Safety I/O connection when a reset command is received, the reset 
command shall be rejected and an error message returned, “Invalid Mode/State”. 

SRS27 The SNCT interface shall provide a special Reset service which requires the password and 
TUNID to execute and supports the 2 common Reset types along with one that can reset to 
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Requirement i 
Number Requirement 

the default but preserve the password 

SRS65 All safety devices on a CIP safety network shall support the baseline Safety Supervisor 
definition. 

SRSI15 If a device has no switches it shall use default values for MAC Id in its out-of-box 
configuration (63) 

SRS116 The UNID of a device shall be stored to NVS as part of the UNID setting operation. 

SRSI17 A device in Manufacturers default state shall have an invalid UNID value in its NVS (e.g. 
OxFF, OxFF, OxFF, OxFF, OxFF, OxFF). 

SRS118 The UNID of a device shall be read from NVS during power up and loaded into an attribute 
of the Safety Supervisor object and Safety_Network_Number attribute of the DeviceNet, 
TCP/IP or SERCOS II object. 

SRS129 To clear an existing OUNID, safety targets shall support a “reset to out-of-box” using a reset 
switch on the device or using the special reset command defined in the Safety Supervisor. 

SRS134 The default for the Configuration UNID shall be all octets set to 0x00 

SRS146 If a TUNID mismatch occurs when sending the Safety Supervisor Safety Reset command, 
the Invalid Parameter error code (0x20) error code shall be returned 

SRS150 If a password mismatch occurs when processing a Safety Supervisor Safety Reset command, 
a Privilege Violation error code (OxOF) shall be returned 

SRS184 The default for SCID attribute in the Safety Supervisor shall be 0 

SRS191 The UNID of a device shall be stored to the DeviceNet, TCP/IP or SERCOS III object's 
SNN attribute as part of the UNID setting operation. 

SRS194 The Propose_TUNID service shall only be accepted when the target device is in the 
Waiting_for_TUNID state. 

SRS195 The Macld portion of the TUNID shall be matched up against the Macld attribute of the 
DeviceNet object. 

SRS196 If an originator wants to cancel a propose/apply operation, sending a propose service with a 
TUNID of all OxFFs shall cancel the operation. 

SRS197 The Apply_TUNID service shall validate the TUNID against the proposed value, stops the 
LED flashing, saves the TUNID to nonvolatile storage, updates the TUNID attribute in the 
Supervisor, and sets the proposed_TUNID attribute to all OxFFs. The Supervisor shall then 
transition to Configuring. 

SRS201 The default for all OCPUNIDs shall be 0 (accept any owner) with the ePath for each 
pointing to the respective resource. 


TST52 The Reset Command Test shall confirm the appropriate behavior for handling Safety 
Supervisor Reset Commands. 


The following procedure will be followed for this test: 


1. Open Explicit Message Connection. 
2: Request a Safety_Open type = 2, SCID = 0, RPI = (100 ms) 


Pass: Success_Response 


3s Complete at least one time coordinated handshake to completely establish the connection 


Request a Safety_Reset, type = 0. 
Pass: Error_Response, 94 0C FF, Object State Conflict 


5. Request a Safety_Close 
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Pass: Success_Response 


6. Request a Safety_Reset, with invalid TUNID. 
Pass: Error_Response, 94 20 FF, Invalid Parameter. 
Ts Request a Safety_Reset, with invalid Password. 
Pass: Error_Response, 94 OF FF, Privilege Violation. 
Type 2 Reset test 


Bit Map = 0, retain nothing 


8. 


20. 


Request a Set_Password, with default Password and new password. 
Pass: Success_Response 
Request a Safety_Reset, type = 2, bit map = 0, with new Password. 
Pass: Success_Response 


Open Explicit Message Connection. 
If Macld is settable, Restore the DUT Macld to previous value. 
Request a Get_Attribute_Single, Safety_Supervisor, CFUNID. 


Pass: Success_Response, CFUNID = default, all zero. 

Request a Get_Attribute_Single, Safety_Supervisor, TUNID. 

Pass: Success_Response, TUNID = default, all Oxff. 

Request a Get_Attribute_Single, Safety_Supervisor, OPCUNID. 
Pass: Success_Response, OPCUNID = default, all zero for UNIDs. 
Request a Get_Attribute_Single, Safety_Supervisor, State. 


Pass: Success_Response, state = 8, waiting for TUNID. 


Bit Map = 1, retain Macld 
6. 


Request a Set_Password, with default Password and new password. 
Pass: Success_Response 
Request a Safety_Reset, type = 2, bit map = 1, with new Password. 
Pass: Success_Response 


Open Explicit Message Connection. 
Request a Get_Attribute_Single, Safety_Supervisor, CFUNID. 


Pass: Success_Response, CFUNID = default, all zero. 
Request a Get_Attribute_Single, Safety_Supervisor, TUNID. 
Pass: Success_Response, TUNID = default, all Oxff. 
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21. 


22. 


23. 


Request a Get_Attribute_Single, Safety_Supervisor, OPCUNID. 
Pass: Success_Response, OPCUNID = default, all zero for UNIDs. 
Request a Get_Attribute_Single, Safety_Supervisor, State. 

Pass: Success_Response, state = 8, waiting for TUNID. 

Configure the DUT. 


Bit Map = 2, retain Baud Rate 


24. 


25. 


26. 
27. 
28. 


29. 


30. 


31. 


32. 


Request a Set_Password, with default Password and new password. 
Pass: Success_Response 
Request a Safety_Reset, type = 2, bit map = 2, with new Password. 
Pass: Success_Response 


Open Explicit Message Connection. 
If Macld is settable, Restore the DUT Macld to previous value. 
Request a Get_Attribute_Single, Safety_Supervisor, CFUNID. 


Pass: Success_Response, CFUNID = default, all zero. 

Request a Get_Attribute_Single, Safety_Supervisor, TUNID. 

Pass: Success_Response, TUNID = default, all Oxff. 

Request a Get_Attribute_Single, Safety_Supervisor, OPCUNID. 
Pass: Success_Response, OPCUNID = default, all zero for UNIDs. 


Request a Get_Attribute_Single, Safety_Supervisor, State. 


Pass: Success_Response, state = 8, waiting for TUNID. 


Configure the DUT. 


Bit Map = 5, retain TUNID and Macld 


33. 


34. 


35. 
36. 
37; 


38. 


Request a Set_Password, with default Password and new password. 
Pass: Success_Response 
Request a Safety_Reset, type = 2, bit map = 4, with new Password. 
Pass: Success_Response 


Open Explicit Message Connection. 
If Macld is settable, Restore the DUT Macld to previous value. 
Request a Get_Attribute_Single, Safety_Supervisor, CFUNID. 


Pass: Success_Response, CFUNID = default, all zero. 
Request a Get_Attribute_Single, Safety_Supervisor, TUNID. 


Pass: Success_Response, TUNID = previous non-default value. 
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39. 


41. 


42. 


50. 


Request a Get_Attribute_Single, Safety_Supervisor, OPCUNID. 
Pass: Success_Response, OPCUNID = default, all zero for UNIDs. 
Request a Get_Attribute_Single, Safety_Supervisor, State. 

Pass: Success_Response, state = 7, Configuring. 


Configure the DUT. 


Bit Map = 8, retain Password 


Request a Set_Password, with default Password and new password. 
Pass: Success_Response 
Request a Safety_Reset, type = 2, bit map = 8, with new Password. 
Pass: Success_Response 


Open Explicit Message Connection. 
If Macld is settable, Restore the DUT Macld to previous value. 
Request a Get_Attribute_Single, Safety_Supervisor, CFUNID. 


Pass: Success_Response, CFUNID = default, all zero. 

Request a Get_Attribute_Single, Safety_Supervisor, TUNID. 

Pass: Success_Response, TUNID = default, all Oxff. 

Request a Get_Attribute_Single, Safety_Supervisor, OPCUNID. 
Pass: Success_Response, OPCUNID = default, all zero for UNIDs. 


Request a Get_Attribute_Single, Safety_Supervisor, State. 


Pass: Success_Response, state = 8, waiting for TUNID. 


Configure the DUT. 


Bit Map = 16, retain CFUNID 


1. 
52. 


56. 


57. 


Password is not set, use new password in Reset request 


Request a Safety_Reset, type = 2, bit map = 8, with new Password. 
Pass: Success_Response 


Open Explicit Message Connection. 
If Macld is settable, Restore the DUT Macld to previous value. 
Request a Get_Attribute_Single, Safety_Supervisor, CFUNID. 


Pass: Success_Response, CFUNID = previous non-default value. 
Request a Get_Attribute_Single, Safety_Supervisor, TUNID. 
Pass: Success_Response, TUNID = default, all Oxff. 

Request a Get_Attribute_Single, Safety_Supervisor, OPCUNID. 
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58. 


59. 


Pass: Success_Response, OPCUNID = default, all zero for UNIDs. 
Request a Get_Attribute_Single, Safety_Supervisor, State. 
Pass: Success_Response, state = 8, waiting for TUNID. 


Configure the DUT. 


Bit Map = 32, retain OCPUNID 


60. 


61. 


62. 


63. 
64. 
65. 


66. 


67. 


68. 


69. 


Send Type2b Safety Open request (to set OCPUNID). 

Pass: Success_Response 

Request a Set_Password, with default Password and new password. 
Pass: Success_Response 

Request a Safety_Reset, type = 2, bit map = 0, with new Password. 
Pass: Success_Response 


Open Explicit Message Connection. 
If Macld is settable, Restore the DUT Macld to previous value. 
Request a Get_Attribute_Single, Safety_Supervisor, CFGUNID. 


Pass: Success_Response, CFGUNID = default, all zero. 
Request a Get_Attribute_Single, Safety_Supervisor, State. 
Pass: Success_Response, TUNID = default, all Oxff. 

Request a Get_Attribute_Single, Safety_Supervisor, OPCUNID. 


Pass: Success_Response, OPCUNID = previous non-default value. 


Request a Get_Attribute_Single, Safety_Supervisor, State. 
Pass: Success_Response, state = 8, waiting for TUNID. 
Configure the DUT. 


Bit Map = 63, retain all attributes 


70. 


71. 


72. 
73. 


74. 


Request a Set_Password, with default Password and new password. 
Pass: Success_Response 
Request a Safety_Reset, type = 2, bit map = 0, with new Password. 
Pass: Success_Response 


Open Explicit Message Connection. 
Request a Get_Attribute_Single, Safety_Supervisor, CFGUNID. 


Pass: Success_Response, CFGUNID = previous non-default value. 


Request a Get_Attribute_Single, Safety_Supervisor, State. 


Pass: Success_Response, TUNID = previous non-default value. 
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75. 


76. 


77. 


Request a Get_Attribute_Single, Safety_Supervisor, OPCUNID. 
Pass: Success_Response, OPCUNID = previous non-default value. 
Request a Get_Attribute_Single, Safety_Supervisor, State. 

Pass: Success_Response, state = 7, configuring. 


Configure the DUT. 


Type 1 reset test 


78. 


79. 
80. 


81. 


Request a Safety_Reset, type = 1, with valid Password. 
Pass: Success_Response 


Open Explicit Message Connection. 


Request a Get_Attribute_Single, Safety_Supervisor, Output Connection Owner. 


Pass: Success_Response, OUNID = 0. 
Request a Get_Attribute_Single, Safety_Supervisor, SCID 
Pass: Success_Response, SCID = 0. 


Establish initial conditions 


82. 


Request a Get_Attribute_Single, Safety_Supervisor, State. 


Pass: Success_Response, state = 8, waiting for TUNID. 


83. 


84. 


Request a Get_Attribute_Single, Safety_Supervisor, Proposed TUNID. 
Pass: Success_Response, value = 0xFFFFFFFF. 

Request a Get_Attribute_Single, Safety_Supervisor, TUNID. 

Pass: Success_Response, value = 0xFFFFFFFF. 


Test detection of nonmatching Macld in TUNID 


85. 


86. 


87. 


Request a Propose_TUNID, TUIND = invalid Macld. 

Pass: Error_Response 94 20 FF, Invalid Parameter 

Request a Propose_TUNID, TUIND = valid. 

Pass: Success_Response 

Request Tester confirm the NET LED Flashing at proper rate 


Pass: Positive visual confirmation 


Test cancellation of proposal 


88. 


Request a Propose_TUNID, TUIND = OxFFFFFFFF. 
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89. 


90. 


91. 


Pass: Success_Response 

Request Tester confirm the NET LED stops flashing 

Pass: Positive visual confirmation 

Request a Get_Attribute_Single, Safety_Supervisor, Proposed TUNID. 
Pass: Success_Response, value = 0xFFFFFFFF. 

Request a Get_Attribute_Single, Safety_Supervisor, TUNID. 

Pass: Success_Response, value = 0xFFFFFFFF. 


Test insensitivity to more than one proposal 


92. 


93. 


94. 


95: 


96. 


97. 


98. 


Request a Propose_TUNID, TUIND = valid. 

Pass: Success_Response 

Request Tester confirm the NET LED Flashing at proper rate 

Pass: Positive visual confirmation 

Request a Get_Attribute_Single, Safety_Supervisor, Proposed TUNID. 
Pass: Success_Response, value = from propose request. 

Request a Get_Attribute_Single, Safety_Supervisor, TUNID. 

Pass: Success_Response, value = 0xFFFFFFFF. 

Request a Propose_TUNID, TUIND = valid. 

Pass: Success_Response 

Request a Propose_TUNID, TUIND = Different valid TUNID. 

Pass: Success_Response 

Request a Get_Attribute_Single, Safety_Supervisor, Proposed TUNID. 


Pass: Success_Response, value = from propose request. 


Test Apply TUNID invalid parameters 


99. Request an Apply_TUNID, TUIND = invalid. 
Pass: Error_Response 94 20 FF, Invalid Parameter 

100. Request an Apply_TUNID, TUIND = valid. 
Pass: Success_Response 

101. Request a Get_Attribute_Single, Safety_Supervisor, Proposed TUNID. 
Pass: Success_Response, value = 0xFFFFFFFF. 

Test valid Apply TUNID 
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102. Request a Get_Attribute_Single, Safety_Supervisor, TUNID. 
Pass: Success_Response, value = TUIND. 

103. Request a Get_Attribute_Single, Safety_Supervisor, State. 
Pass: Success_Response, state = 7, configuring. 


104. Prompt tester to power cycle device 
105. Open Explicit connection 
106. Request a Get_Attribute_Single, Safety_Supervisor, State. 


Pass: Success_Response, state = 7, configuring. 


107. Request a Configure_Request, Password = default (all zeros). 
Pass: Success_Response 


108. Configure the DUT. 
109. Request a Get_Attribute_Single, Safety_Supervisor, State. 


Pass: Success_Response, state = 2, idle. 
110. Request a Safety_Reset, type = 0, with valid Password. 
Pass: Success_Response 


111. Open Explicit Message Connection. 
112. Request a Get_Attribute_Single, Safety_Supervisor, State. 


Pass: Success_Response, state = 2, idle. 


F-3.11.5.3 — TST53 - Configuration Lock/Unlock Test 


Requirement . 
Naimber Requirement 

SRS10 If an originator attempts to configure a device with the Configuration Lock attribute set, the 
device shall reject the SafetyOpen and return an error message “Configuration Not Allowed” 
is returned 

SRS25 The SNCT interface shall provide a Configuration Lock service which requires the password 
and TUNID to execute 

SRS31 Safety devices which support the SNCT interface shall require that the “Configuration Lock” 
attribute be cleared before any command to change a safety device to the Configure State 
(Configure_Request) will be accepted. 

SRS32 When the Configuration Lock attribute is set, the device shall reject any Type 1 Safety Open 
messages. 

SRS68 The Configuration Lock attribute, when implemented with the SNCT interface, shall be used 
to mark the device configuration as verified and to lock down the configuration; 0 = 
Unlocked (unverified and changeable), 1 = Locked (verified and not changeable). 

SRS72 When a Configure_Request is received, if the Configuration_Lock attribute is set, a 
“Configuration Operation Not Allowed” error shall be returned. 

SRS132 The SNCT Configuration Lock Attribute shall have a default value of “Unlocked” 

SRS145 If a TUNID mismatch occurs in the Safety Supervisor Configuration_Lock/Unlock 
command, the Invalid Parameter error code (0x020) shall be returned 
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Requirement i 
Naabee Requirement 

SRS149 If a password mismatch occurs when processing a Safety Supervisor 
Configuration_Lock/Unlock command, a Privilege Violation error code (OxOF) shall be 
returned 

SRS199 While a device has the Configuration Lock attribute set, it shall reject Configure_Requests, 
Type | & 2 Safety Reset, and any valid Type 1 SafetyOpen. 

SRS200 When a Type 1 or Type 2 Safety Reset is received, if the Configuration_Lock attribute is set, 
a “Object State Conflict error code (0x0C)” shall be returned 


TST53 The Configuration Lock/Unlock test shall confirm that the DUT supports all the 
Configureation Lock/Unlock requirements. 


The following procedure or something similar should be followed: 


Ly Commission the DUT with Macld, reset to Out-of-Box, and set the TUNID 
2: Open a Class 3 connection 
3. Configure the DUT with a representative configuration. Leave the PW at the default. 
4, Send a Get_attribute to the Supervisor’s Configuration Lock attribute 
3: Confirm the attribute is equal to 0 
6. Open a Class 3 connection 
7. Send the Configuration Lock Command to the safety supervisor with an invalid PW 
8. Confirm the message is rejected and a Privilege Violation (OxOF) error is returned 
9. Send the Configuration Lock Command to the safety supervisor with an invalid TUNID 
0. Confirm the message is rejected and an Invalid Parameter (0x20) is returned 
Send the Configuration Lock Command (=1) to the safety supervisor with an valid PW. 
and TUNID 
2. Confirm the message is accepted 
3. Send a Get_Atrribute to the Configuration_Lock attribute 
4. Confirm the value is equal to | 
5. Close all connections and power cycle the device 
6. Attempt to configure the device via all supported mechanism (i.e. type 1 and/or Tool 


interface) 
7. Confirm the device rejects all Type 1 connections and/or a valid Configure Requests (i.e. 
valid parameters) 


8. Confirm the error code returned is 0x01 extended code 0x80F (configuration operation 
not allowed) 


9. Send a valid Configure_Request and confirm error code 0x0C, Object state conflict is 
returned. 


20. Senda Type | and Type 2 reset command 

21. Confirm both requests return error code 0x0C, Object state conflict. 
22. Senda Type 0 Reset 

23. Confirm the request is accepted 


24. Open a Class 3 connection and clear the Configuration Lock 
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25. Power cycle the device 
26. Confirm the DUT Safety Supervisor state = (2) Idle 
27. Attempt to configure the device via all supported mechanisms 


28. Confirm the device now accepts all configuration attempts 


F-3.11.5.4 TST54 - Configure_Request Test 


Requirement ‘ 
Meer Requirement 

SRS24 The SNCT interface shall provide a Configure Request service which requires password, 
TUNID, and OUNID to execute 

SRS33 The configuration mode in safety devices implementing the SNCT interface shall persist 
through power cycles. 

SRS34 Upon entering the configuration mode, devices implementing the SNCT interface shall: 

Store the configuration mode in NVS_ Mark the existing configuration invalid Lock out 
all configuration messages for connections other that the one that set the configuration mode. 

SRS35 To enter the configuration mode, devices implementing the SNCT interface shall: confirm 
User Password in the configuration mode command confirm TUNID in the configuration 
mode command 

SRS73 When the Configure Request command is accepted, the device shall only accept 
configuration messages to safety relevant objects over “this connection only”. Any attempts 
to write to safety-relevant objects over other connections shall be rejected. 

SRS74 If a configuration connection fails for any reason, another Configure_Request shall be 
received (establishing a new connection source) before configuration changes can be made 
(even after a power-cycle) 

SRS116 The UNID of a device shall be stored to NVS as part of the UNID setting operation. 

SRS130 In the SNCT interface, an unowned device shall capture the OUNID as the device owner 
when the first Configure_Request is received. 

SRS136 All safety devices shall support a non-volatile configuration mode, this means that once a 
device is commanded to enter the configuration mode it shall remain in the configuration 
mode until the configuration is successfully validated. 

SRS143 If a TUNID, OUNID mismatch error occurs when processing a Safety Supervisor Configure 
Request, an Invalid Parameter (0x20) error code shall be returned 

SRS147 If a password mismatch occurs when processing a Safety Supervisor Configure Request, a 
Privilege Violation (OxOF) error code shall be returned 


TST54 The Configure Request Test shall confirm that the connection target enters the 
configuration mode only when a properly presented Configuration Request is issued with the 
proper parameters . 


The following procedure will be followed for this test: 


Commission the DUT with a Macld 

Power cycle the device 

Open a Class 3 connection to an out-of-box DUT (password at default) 

Send a Get_Attribute to the TUNID attribute in the Safety Supervisor 

Confirm that the TUNID matches the configured values for SNN and Macld 
Send a Configure_Request service to the Safety Supervisor with an invalid PW 
Confirm the request is rejected and Privilege violation (OxOF) error is returned 


DOA TON SON. ABS G0) CRO: ES 


Send a Configure_Request service to the Safety Supervisor with an invalid TUNID 


—F-93- 
Edition 2.3 
SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Appendix F: Safety Test Plan 


9. Confirm the request is rejected and an Invalid Parameter (0x20) error is returned 


0. Send a Configure_Request service to the Safety Supervisor with a valid PW, TUNID, 
and non-tool OUNID 


Confirm the request is accepted 
Open another Class 3 connection 


Send a Configure_Request service to the Safety Supervisor with a valid PW, TUNID but 
another OUNID 


Confirm the request is rejected 

Close connections and power cycle the device 
Reopen a Class 3 connection to the DUT 
Confirm the DUT is in the Configuring state 


Send a Set_Attribute to an safety relevant parameter 


Oo OA A 


Confirm the DUT rejects the message (it needs to get a new Configure Request first) 


20. Send a Configure_Request service to the Safety Supervisor with a valid PW, TUNID, 
and another OUNID 


21. Confirm the request is rejected with an Invalid Parameter (0x20) error is returned 


22. Send a Configure_Request service to the Safety Supervisor with a valid PW, TUNID, 
and the original OUNID 


23. Confirm the request is accepted 
24. Complete the DUT configuration 


25. Confirm the configuration is accepted 


F-3.11.5.5 | TST55 - Configuration Process Test 


Requirement 
Number 


Requirement 


FRSI16 The following Rules shall apply to device configuration: 

Devices being configured shall not have any active safety connections and shall not be in the 
executing mode. 

Once configuration of a device starts, the device shall remain in the non-operational mode 
until the configuration process is successfully completed. This mode shall be maintained 
through power cycles. 

If a device is in an operational mode (e.g.. has active connection or is in executing mode), it 
shall reject any configuration messages. 


SRS26 The SNCT interface shall provide a Validate Configuration service which requires the SCID, 
SCCRC, and the SCTS to execute 

SRS36 A receiving SIL3 device shall calculate a SCCRC with SIL3 integrity and compare it to the 
SCCRC within the SCID 

SRS90 The SCCRC shall be calculated over the configuration data by the device whenever a device 
configuration is validated (i.e. Validation Request to the safety supervisor or type | safety 
connection) 

SRS9I The SCCRC shall be saved to NV storage along with the other NV attributes whenever a 
configuration is applied (i.e. apply request to the safety supervisor). 


SRS131 The SNCT interface shall provide an Apply service that causes the device to save the 
configuration to NV memory. 


SRS138 Any explicit messages are allowed to set configuration in the device, but the device shall only 
accept safety-related explicit messages over the connection that put it into the configuration 
mode. 
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Requirement A 
Naibee Requirement 
SRSIS51 If the Safety Supervisor Validate_Configuration command does not succeed, the error 
response shall send a class defined “Validation Error” (OxDO) 
SRS198 When a device enters Configuring mode, the SCID attribute shall be set to 0 and maintained 
at this value (through power cycles) until a successful Validate has been executed. 


TSTS55 The Configuration Process Test shall confirm that the DUT follows the basic safety 
configuration procedure dictated by the Safety Supervisor 


The following procedure will be followed for this test: 


ae 


an NOOO) 228L ON Ns BS. G0) 
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Open a Class 3 connection to the DUT 


Send a set attribute service to a safety related configuration object (ie. Configuration 
assembly, attr. 3) 


Confirm the DUT responds with a Mode/State error 

Send a Configure_Request with the proper parameters (ie. Password, OUNID) 

Get and confirm that the SCID = 0 

Send the same Set_Attribute service as before 

Confirm the device accepts the message 

Power cycle the device 

Open a Class 3 connection with the DUT 

Get and confirm that the SCID = 0 

Read the Safety Supervisor state attr and confirm the state is Configuring 

Send the same Set_Attribute service 

Confirm the device rejects the service (you need to resend the Configure_Request first) 
Send a Configure_Request with the proper parameters 

Send the same Set_Attribute service as before 

Confirm the device accepts the message 

Open another Class 3 connection (as if another configuration device were connecting) 
Send a Set_Attribute service to a safety relevant parameter over this new connection 
Confirm that the set attribute is rejected 

Send a complete configuration over the original connection 

Send a Validate Configuration Request with a invalid CRC in SCID 

Confirm the device sends a Validation Error (Ox0D, 01) 

Send a Validate Configuration Request with a valid SCID 

Confirm the device sends a success reply 

Inspect the returned SCID and confirm the SCCRC matches the value sent. 

Send a Configuration Apply 

Close connections and power cycle device 

Confirm the DUT is in the IDLE state and the configuration SCID is correct 
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F-3.11.5.6 TST56 - Setting Passwords Test 


Requirement rt 
Naber Requirement 

SRS17 Support for one password shall be implemented by devices supporting the SNCT interface 

SRS20 The default password value in devices supporting the SNCT interface shall be zero 

SRS22 The SNCT interface shall support a Password service to set passwords which takes 2- 
password parameters; Old PW and New PW 

SRS148 If a password mismatch occurs on the current password when processing a Safety 
Supervisor Set Password command, a Privilege Violation error code (OxOF) shall be 
returned 


TST56 The Setting Password Test shall confirm a number of the password feature requirements 
are being met. 


The following procedure will be followed: 

Ly Request a Safety_Reset, type = 1. 
Pass: Success_Response 

2: Request a Propose_TUNID, TUIND = valid. 
Pass: Success_Response 

3. Request an Apply_TUNID, TUIND = valid. 
Pass: Success_Response 


4. Open an Explicit Message Connection 
3: Request the default Configure_Request, password = default (all zeros). 


Pass: Succcess_Response 

6. Request a Set_Password, old = not default, new = default. 
Pass: Error_Response, 94 OF FF, Privilege Violation 

qt Request a Set_Password, old = default, new = non-default. 
Pass: Succcess_Response 

8. Request a Safety_Reset, type = 0. 
Pass: Success_Response 


9. Open an Explicit Message Connection. 


10. | Request a Configure_Request, password = new password 
Pass: Succcess_Response 


11. Configure the DUT. 
12. Request a Validate_Configuration with valid SCID 


Pass: Succcess_Response 


13. Request a Set_Password, old = new password, new = default. 
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F-3.11.5.7 


F-3.11.6 
F-3.11.6.1 


Pass: Succcess_Response 


TST57 - Mode Change Test 
Requirement Fs 
INGE Requirement 
SRS28 The SNCT interface defines an optional Mode Change service which, if implemented, shall 
require a password to execute 
SRS144 If a password mismatch occurs in the Safety Supervisor Mode Change command, an 


Privilege Violation error code (OxOF) shall be returned 


TST57 The Mode Change Test shall confirm that devices which support the Mode change also 
require the proper Password parameter to execute 


The following procedure will be followed: 


Request 
Verify 

Request 
Verify t 
Request 


Verify 
Request 


seo ernaunarnn 


11. Verify t 


Open a Class 3 connection to the DUT 


Type 0 Safety Reset 

at the Safety Supervisor state = 2, Idle 

Mode_Change service, state = RUN with invalid password 

at the error response with general status OxOF, Privilige Violation 
Mode_Change service, state = RUN with valid password 


Verify that the success response 


at the Safety Supervisor state = 4, Executing 


Mode_Change service, state = Idle with valid password 


0. Verify that the success response 


at the Safety Supervisor state = 2, Idle 


Safety Validator Object Tests 


TSTS58 - Safety Connection Diagnostics 


Requirement rR 
NGA DSE: Requirement 
SRS75 This Safety Connection Fault Count attribute in the Safety Validator shall be a running count 
(with auto-rollover) of how many times any safety connection was faulted for any reason. 
SRS78 The Max Data Age attribute shall always reflect the largest value the connection’s data age 
reaches without exceeding the expectation multiplier. 
SRS79 If a safety connection is ever faulted and closed, the Max Data Age attribute shall be re- 


initialized to 0 when the connection is re-established. 


TSTS8 The Safety Connection Diagnostic test shall confirm that the DUT supports the 
diagnostic attributes and the behavior is correct. 


The following 


GOS 


ne 


procedure will be followed for this test: 


Commission and configure the DUT with a representative configuration 
Establish a safety connection wth the device 

Open a Class 3 connection to the DUT 

Send a Get_Attribute to Validator class to read the Fault count attribute 

Send a Get_Attribute to Validator instance to read the Max Data Age attribute 
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F-3.12 


F-3.12.1 


F-3.12.2 


Generate a Safety connection fault by sending bad safety CRCs 


Te After the safety connection has closed, send a get attribute to the validator class and 
confirm the Fault count was incremented. 


8. Re-establish the safety connection 


Generate increasing delays in communication to cause the Data age to increase in the 
device but within the tolerance of the connection 


10. Send a get attribute to the Max Data Age and confirm the value increases as the delay is 
increased. 


11. Cause the safety connection to fault again 
12. Once the connection gets closed, reopen it 


13. Send a get attribute to the Max Data Age and confirm the value is reset to 0. 


DeviceNet Bridge Device Tests 


The following tests are provided to aid in the development of standard conformance testing of 
bridging/router devices which have implemented safety routing functionality. The 
requirements referenced here are all non-safety-related interoperability requirements. 


TST62 - DeviceNet Bridge FW_Open to SafetyOpen Conversion 


Requirement ~ 
Number Requirement 
Interoperability The last router/bridge in a multi-hop connection shall convert the Forward_Open 


requests received from a higher-level network into the equivalent Safety Open request 


Requirement only ( h 
when the target is on DeviceNet. 


TST62 The DeviceNet Bridge FW_Open to SafetyOpen Conversion test shall confirm that the 
DeviceNet bridge DUT will perform the conversion properly. 


TST63 - DeviceNet Bridge Non-Dnet-to-Dnet Forwarding Test 


Requirement fe 
Naber Requirement 
Interoperability A non-certified DeviceNet Bridge, bridging a multi-cast production from a Non- 
Requirement only DeviceNet network to a DeviceNet network shall forward a Data Message consisting of 
a Data&Time_Stamp section onto the DeviceNet network, once and only once, any time 
a Data Message is received from the Non-DeviceNet 
Interoperability A non-certified DeviceNet Bridge, bridging a multi-cast production from a Non- 


DeviceNet network to a DeviceNet network shall forward a Time_Correction Message 
onto the DeviceNet network, once and only once, any time a Data Message is received 
from the Non-DeviceNet network with a Time Correction section - 
MCast_Byte.Consumer_Num equal to a value other than 0x0. If the 
MCast_Byte.Consumer_Num is equal to 0x0 (Null Time_Correction section), the 
Time_Correction Message shall not be forwarded 


Requirement only 


Interoperability The non-certified DeviceNet Bridge shall not translate a Time_Coordination Message. 


Requirement only __| It is forwarded upon reception. 


Interoperability The DeviceNet Bridge shall never create or modify Safety CRCs for the 
Data&Time_Stamp, Time_Correction, or Time_Coordination sections. 


Requirement only 


TST63 The DeviceNet Bridge Non-Dnet-to-Dnet Forwarding Test shall confirm that the 
required rules for forwarding safety Data messages are being followed. 
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F-3.12.3 


The following procedure will be followed: 


1. Set up a system with a tester acting as a multi-cast producing target on a non-DeviceNet 
network and a tester acting as 5 multi-cast originators on DeviceNet. 


Originate a connection to the target through the bridge DUT 


3: Count production data messages sent to the multi-cast consumers 

4. Confirm that the number of messages sent equals the number captured by the consuming 
tester 

3: Send a predefined number of data productions with the Mcast_Byte Consumer Num = 0 


Confirm the bridge does not produce Time Correction messages 
Ts Begin sending the data productions with the Mcast Byte Consumer Num with non-zero 


values 
8. Confirm the Time Correction message are forwarded as sent 
9. Confirm the CRCs are never corrupted or incorrect at any time during the test 


TST64 - DeviceNet Bridge Dnet-to-nonDnet Forwarding Test 


Requirement 


Naiiber Requirement 


Interoperability When multi-cast connections are bridged between DeviceNet and other Non-DeviceNet 
networks, the safety-aware DeviceNet bridge shall translate the connections from three 


Requirement only Z : a 
messages on DeviceNet to two connections on Non-DeviceNet Networks 


Interoperability The safety-aware DeviceNet bridge shall execute the 3-to-2 multi-cast safety 
connection translation by concatenating the safety data message and the time correction 


Requirement only i, 
message at the bridge. 


Interoperability The non-certified DeviceNet Bridge shall not translate a Time_Coordination Message. 


Requirement only It is forwarded upon reception. 


Interoperability A non-certified DeviceNet Bridge, bridging a multi-cast Data Message and 
Time_Correction Message from a DeviceNet network to a Non-DeviceNet network 
shall send a Data Message consisting of a Data&Time_Stamp section and a Time 
Correction section onto the Non-DeviceNet network any time it receives a Data 
Message consisting of a Data&Time_Stamp section from the DeviceNet network. 


Requirement only 


Interoperability Every Time_Correction Message or Messages received from the DeviceNet network 
shall be forwarded once and only once in order, in the Time Correction section of the 
Non-DeviceNet Data Messages that are triggered by the reception of the DeviveNet 
Data Message. 


Requirement only 


Interoperability When sending a Data Message onto the Non-DeviceNet network, if there are no 
Time_Correction Messages to be forwarded, the previous Time_Correction section 
shall be sent with the MCast_Byte.Consumer_Num equal to 0x0 (Null 
Time_Correction section). 


Requirement only 


Interoperability For the case of the first Data Message being sent onto Non-DeviceNet before a 
DeviceNet Time_Correction Message has been received, a Time_Correction section of 


Requirement only 
all 00’s shall be sent. 


Interoperability The DeviceNet Bridge shall never create or modify Safety CRCs for the 
Data&Time_Stamp, Time_Correction, or Time_Coordination sections. 


Requirement only 


TST64 The DeviceNet Bridge Dnet-to-nonDnet Forward Test shall confirm that the required 
tules for forwarding safety data messages to non-devicenet networks are followed. 
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F-3.13 


F-3.13.1 
F-3.13.1.1 


F-4 


The following procedure will be followed: 

1. Set up a system with a tester acting as 5 multi-cast consuming originators on a non- 
DeviceNet network and a tester acting a multi-cast producer on DeviceNet. 
Open the connections to the producer through the bridge DUT 


3: Confirm that the bridge DUT constructs the proper SafetyOpen with the extra Time 
Correction connection 


4. Send production data without Time Correction messages 

3: Confirm the bridge DUT sends message on the non-DeviceNet side with Time 
Correction section consisting of all 00’s. The CRC for this is irrelevant and should be 
ignored. 


Sending a Time Correction message to one of the consumers 


4: Confirm that the the produced data with the correct Time Correction section added (with 
a proper CRC) 
8. Confirm that all Time Correction messages get forwarded only one time and all 


subsequent production are followed by a Null Time Correction 
9. repeat for all the other consumers. 
10. Confirm the all data and time stamp section CRCs are always correct 


Standard CIP Message Interaction 


Standard Messaging Rejection 
TST65 - Standard messaging to Safety I/O 


Requirement 


Number Requirement 


FRS8 Safety consumer shall detect standard messages as an incorrectly formed message. 


TST65 This test shall set up a safety I/O connection of a type supported by the DUT and send a 
standard slave I/O message over the connection. The test will confirm that the device detects 
the message as an improper format and reject the message. 


White Box Tests 


White box tests are those executed by the product developer. Because of the lack of adequate 
external visibility to certain aspects of the protocol, those requirements which are not externally 
testable will be placed in the White box test area. It will be the responsibility of the product 
developer to generate appropriate tests to confirm the product is meeting these requirements. It 
is beyond the scope of this document to define exactly how the requirements are confirmed. 
Many may be simply done through code inspection or design review. 
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F-4.1 
F-4.1.1 


F-4.1.2 


Application Behavior 


TST61 - Safety Input Application Behavior Test 


Requirement A 
Raniber Requirement 

FRS117 If a safety data state exists for the safety-input device, the device shall transmit safety data 
and the Run_Idle bit shall be set to the idle state upon detection of a fault by the input 
circuit diagnostics. 

FRS118 Changes in the state of the physical process inputs of a safety device shall be transmitted at 
the next available periodic update time. 

SRS48 The default safety state for digital inputs and outputs shall be off. 


TST61 The Safety Input Run/Idle test shall confirm that input device applications behave 
properly. 


The following procedure will be followed for this test: 


Establish a Safety connection to an Input DUT with a representative configuration 
Once the safety connection is established, confirm the Run/Idle bit goes to Run 

Set the physical inputs to a non-safety-state and confirm the produced data reflects the 
inputs 

Create a fault condition to cause the DUT to go to safety-state 

Confirm the Run/Idle bit goes to Idle and the data is set to its safety-state 


TST60 - Safety Output Application Behavior Test 


Requirement 
Number 


Requirement 


SRS48 The default safety state for digital inputs and outputs shall be off. 


FRS288 If consumed safety data becomes older then Network_Time_Expectation_Multiplier, the 


safety data shall be put in the safety state 


TST60 The Safety Output Application Behavior Test shall confirm that the output device 
always safety-states to the off condition. 


The following procedure will be followed for this test: 


1. 
2: 


w 


SD 


Establish a Safety connection to the Output DUT with a representative configuration 


Once the safety connection is established, confirm the Run/Idle bit goes to Run and send 
non-zero output data 


Confirm the outputs are driven to non-zero states 

Delay communication until the DUT application detects a data age error 
Confirm the outputs go to the zero state 

Re-establish communication 


Create any and all additional application specific fault conditions to cause the DUT to go 
to safety-state 


Confirm the outputs go to the zero state 
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F-4,.2 
F-4.2.1 


F-4.2.2 


F-4.2.3 


F-4.2.4 


Consumer Behavior 


TST66 - Consumer Initialization 


Requirement 4 
Numer Requirement 

FRS278 At connection establishment, all S_Run_Idle_Out flags shall be set to Idle. 

FRS292 Since the initial production of safety data should have a Ping_Count of 00, the 
Last_Ping_Count shall be initialized to 11. 

FRS297 When a connection is first established, the Time_Coordination_Count_Down shall be 
initialized to 0. 

FRS300 When a connection is first established, the Last_Data_Time_Stamp shall be initialized to 0. 

FRS302 When a connection is first established, the Last_Reved_Multi_Cast_Active_Idle shall be 
initialized to 0. 

FRS304 When a connection is first established, the Last_Reved_Time_Correction_Value shall be 
initialized to 0. 


TST66 The designer shall confirm via inspection or design review that the safety protocol 
consumer variables are re-initialized on connection establishment 


TST67 - Consumer Mode Byte Processing 


Requirement b 
Nite Requirement 
FRS37 The Base Format Mode byte processing within the CRCs shall be done as shown as 
follows. 
CRC Type Mode byte logic 


Actual DataCRC Mode Byte AND 0xE0O. 

Complement Data CRC (Mode Byte XOR OxFF) 
AND OxE0O 

Time Stamp Section CRC — Mode Byte AND OxIF 


TST67 The Designer shall verify that the consumer FW is properly isolating and including the 
correct Mode Byte sections in the CRC calculations 


TST68 - Consumer Time Value Sampling 


Requirement = 
Number Requirement 
FRSS1 Consumer_Time_Value in the Time Coordination message shall (as closely as possible) 


mark the time at which the consumer sends a ping response message 


TST68 The designer shall confirm that the design is sampling the consumer time value as close 
as possible to the point at which the Time Coordination reponse is sent. 


TST69 - Consumer Time Coordination Generation 


Requirement A 
Number Requirement 

FRS294 The Time_Coordination_Count_Down shall be set equal to the Consumer_Number upon 
the reception of a multi-cast ping request. 

FRS295 The consumer shall decrement the Time_Coordination_Count_Down value on subsequent 
reception of consumed data until the value is equal to 0 

FRS296 If the Time Coordination Count Down value is equal to I during any reception of consumed 
data, the ping response for that consumer shall be sent 
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F-4.2.5 


F-4.2.6 


TST69 The Designer shall confirm via inspection or design review that the Time Coordination 
distribution function provided by the Time Coordination Count Down mechanism is behaving 
as required for all possible consumer numbers. 


TST70 - Consumer Timeout Multiplier Handling 


Requirement ki 
Rinubes Requirement 

FRS82 Safety communications shall be configurable with production repeated. 

FRS83 When safety communication is sent with repeated production, application-triggered 
consumers shall use the last packet received to complete the transaction, as show in Figure 
25: 

FRS88 Valid repeated messages shall be overwritten. The most recent valid message is used by the 
application 


TST70 The designer shall confirm that the device supports the valid range of Timeout 
Multipliers and uses the latest data when overproduction is used 


1; Setup a series of connections with the DUT with Timeout Multipliers equal to 1, 2, 3, 
and 4. 

2. Set the EPI to occur at a rate that exceeds the application sampling rate (this only applies 
to application triggered consumers) 


3: Deliver data with different data each production 

4, Confirm that the data issued to the application is always the latest data available 
53 Repeat this test for all consumer types supported 

6. Confirm that the consumer captures the Time Stamp in the redundant arrivals 


TST71 - Multi-Cast Consumer Time Correction Handling 


Requirement A 
Number Requirement 

FRS28 The Multi-cast safety data consumer shall use the Producer_Time_Stamp and the 
Time_Correction_Value to derive a Data_Time_Stamp that is relative to the safety data 
consumer’s clock. 

FRS61 Consumer_Time_Correction_Value in the Time Correction message shall be used to correct 
the data time stamp and make the time relative to the multi-cast consumers clock. 

FRS286 The Multi-cast consumer shall enable time stamp checking upon the reception of the first 
time correction section. 

FRS298 For multi-cast, the Corrected_Data_Time_Stamp shall be a sum of the received time stamp 
and the Last_Rcved_Time_Correction_Value 

FRS303 The Last_Reved_Time_Correction_Value shall be used to correct the Time Stamp for each 
multi-cast consumer. 

FRS306 When the Time_Correction_Received_Flag is set, the consumer shall begin the process of 
correcting and checking the time stamp. 


TST71 The designer shall perform a test that simulates a series of Time Correction Messages 
with various Time Correction Values and confirm the design applies these values to adjust the 
Data Time Stamp. The designer shall confirm that Time stamp checking is held off until the 
first Time Correction message is received. 
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F-4,2.7 TST72 - Message Age Failure Indication 


Requirement R 
Namber Requirement 

FRS340 Consumer_Clk_Count at the time that the data is given to the consuming application for 
use and the Data_Time_Stamp sent with the data exceeds the 
Network_Time_Expectation_Multiplier, the S_Con_Flt_C_Out flag shall be set to 
“Faulted” to indicate that the Reaction Time for the network has not been met. 

FRS284 If the consumer receives the Data_Time_Stamp as a value other than 0, the time stamp 
checking shall be enabled. 


TST72 The designer shall determine via design review or unit test that the data age test is 
functioning correctly and the application is notified by faulting the connection. Confirm the 
age checking is held off until a non-zero time stamp is received. 

F-4.2.8 Link-Triggered Behavior 

F-4.2.8.1 TST73 - Link-Triggered Consumer Behavior Checks 


Requirement & 
Nuhee Requirement 

FRS127 the Safety ValidatorServer shall perform the following aspects of the safety data 
monitoring: 
Time coordination with the producer 
Time stamp section integrity checking 
Data integrity checking 
Network time expectation checking 

FRS128 The Link Triggered Safety ValidatorServer shall perform all aspects of the safety protocol 
on each message received. 

FRS129 For multi-cast, the Link Triggered Safety ValidatorServer shall also perform all aspects of 
the safety protocol on each Time_Correction section received. 

FRS130 The SafetyValidatorServer shall insure that the safety data presented to the consuming 
application has been crosschecked and that the network time expectation is being met. 

FRS131 The Link Triggered Safety ValidatorServer shall set the new data flag each time data is 
ready for consumption. 


TST73 The designer shall confirm that the Link-triggered safety designs performs all the 
required checks on Time coordination, Time stamps, and Data crosschecking on each reception 
and signals the application. The designer shall also confirm that multi-cast connection process 
Time correction messages on reception. 


F-4.2.9 Application-Triggered Behavior 
F-4.2.9.1 TST74 & TST75 - Application Triggered Consumer Behavior Checks 


Requirement 7 
Nanmiber Requirement 

FRS127 the Safety ValidatorServer shall perform the following aspects of the safety data monitoring: 
Time coordination with the producer 
Time stamp section integrity checking 
Data integrity checking 
Network time expectation checking 

FRS132 The process reception stage (Figure 45) of the application triggered Safety ValidatorServer 
shall check the ping count for all incoming data messages. 
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F-4.2.10 


F-4,2.11 


Requirement A 
Number Requirement 

FRS133 For multi-cast consumption in application triggered Safety ValidatorServers, the latest 
Time_Correction section received shall be forwarded to the consuming application. 

FRS134 The consuming safety application shall request new data from the SafetyValidatorServer in 
order to cause the Safety ValidatorServer to complete processing of a message. 

FRS135 The consuming application shall ensure that it gets new data at least once every 2 seconds 
to ensure that the time stamp does not rollover. 


TST74 The designer shall confirm that the application triggered safety designs check the ping 
count (and consumer # for multi-cast) on arrival and captures the Time Correction sections 
when the consumer number matches in the multi-cast case. 


TST75 The designer will confirm that when the application requests new safety data, stage 2 


consumer processing is executed. The designer shall confirm that the application makes this 
request at once every 2 seconds. 


TST76 - Data Integrity Check Time Limit 


Requirement 3 
INGTDES! Requirement 
FRS145 The data integrity shall be checked at least once every 2 seconds. 
FRS146 The Time Stamp and Network Time Expectation (NTE) shall be checked at least once 
every 2 seconds 


TST76 The Designer shall confirm via design review or special test that the device design has 


a mechansim implemented that assures the safety protocol will be executed at least once every 
2 seconds. 
TST77 - Safety Consumer/A pplication Interface 
Requirement 7 
Namben Requirement 
FRS34 Run_Idle shall be used to indicated the usability of the data as determined by the Producer 
Safety Application 
FRS276 S_Run_Idle_Out shall be used by a consuming application to determine if it should put the 
safety data in a safety state. 
FRS277 The S_Run_Idle_Out shall indicate Idle when either the producing application is Idle or the 
Safety Validators are not active 
FRS274 The Connection Status of consuming safety connections shall be indicated as shown in 
Table 2-4.2 of Volume 5 Chapter 2 
FRS279 S_Run_Idle_Out shall be in Idle until Init_Complete_Out is set to a 1. 
FRS301 The Last_Reved_Multi_Cast_Active_Idle shall be used to detect a change from active to 
idle, which would be considered a fault. 
TST77 The designer shall confirm via design review of system test that as application uses the 
S_Run_Idle to decide when to the consumed safety data into the safety sate. The designer shall 


also confirm that once a producer has gone Active, a transition to Idle will cause the connection 
to fault and the application faulted 
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F-4.3 Producer Behavior 


F-4.3.1 TST78 - Producer Initialization 


Requirement 4 
Mace Requirement 

FRS263 At connection establishment, all Consumer_Time_Value variables shall be set to 0x0000. 

FRS266 At connection establishment, all Producer_Rcved_Time_Value variables shall be set to 
0x0000. 

FRS268 At connection establishment, all Consumer_Time_Correction_Value variables shall be set 
to 0x0000. 

FRS273 At connection establishment, all Ping_Int_Since_Last_Time_Coord_Msg_Count variables 
shall be set to 0x0000 

FRS275 At connection establishment, all S_Con_Flt_C_Out flags shall be set to OK. 


TST78 The designer shall confirm via inspection or design review that the safety protocol 
variables are re-initialized on connection establishment. 


F-4.3.2 TST79 - Producer Mode Byte Processing 


Requirement & 
Number Requirement 
FRS37 The Mode byte processing within the CRCs shall be done as shown as follows. 


CRC Type Mode byte logic 

Actual DataCRC Mode Byte AND 0xE0 

Complement Data CRC (Mode Byte XOR OxFF) 
AND OxE0 

Time Stamp Section CRC Mode Byte AND 0x1F 


TST79 The Designer shall verify that the consumer FW is properly isolating and including the 
correct Mode Byte sections in the CRC calculations 


F-4.3.3. TST80 - Producer Time Coordination Response Handling 


Requirement 


Naniber Requirement 
FRS72 The producer shall use the clock count in the Time Coordination response to calculate an 
offset that will be applied to future productions. 
FRS73 At each scheduled production, the producer shall use the value of its own clock count and 
the offset to calculate the time stamp and sends it to the consumer along with the data. 
FRS229 The Timeout_Multiplier shall be used to determine how many ping intervals 


(Timeout_Multiplier.PI+2) a producer will wait before faulting a consumer who has failed 
to send a Time Coordination response to a Ping request 
FRS260 The Time_Drift_Since_Last_Time_Coord shall be used to indirectly determine if the delay 


of the Time Coordination message received is significantly greater than the delay for the 
Time Coordination message previously being used. 


FRS261 Since the maximum time drift is controlled, either the Last Time_Correction_Value minus 
the Time_Drift_Since_Last_Time_Coord value, or the New Time_Correction_Value value, 
shall be sent to the consumer, whichever is better. 


FRS262 For multi-cast producers, a Time_Drift_Since_Last_Time_Coord shall exist for each multi- 
cast consumer, | through Max_Consumer_Number. 


FRS264 Producer_Reved_Time_Value shall be set equal to Producer_Clk_Count at the point in time 
that the Time Coordination Message information is received from the time stamp consumer. 
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F-4.3.4 


Requirement . 
Namiber Requirement 

FRS265 A Producer_Reved_Time_Value shall exist for each multi-cast consumer, | through 
Max_Consumer_Number. 

FRS269 For single-cast connections, the Ping_Int_Since_Last_Time_Coord_Msg_Count shall be 
incremented at the 8th EPI production of the Ping Interval. 

FRS270 For multi-cast connections, Ping_Int_Since_Last_Time_Coord_Msg_Count shall be 
incremented every (8 + n)th EPI production of the Ping Interval, where n equals the 
consumer number - 1. 

FRS271 The Ping_Int_Since_Last_Time_Coord_Msg_Count for any particular consumer shall be 
reset upon the reception of a valid Time Coordination Message from that consumer 

FRS272 If the Ping_Int_Since_Last_Time_Coord_Msg_Count ever exceeds the 
Timeout_Multiplier.PI + 2 for a connection, that consumer shall be set to the faulted state 

FRS320 If the Consumer_Active_Idle[Consumer_Num-1] == Active, Producers shall check that 
Time Coordination Messages are received within the Time_Coord_Response_EPI_Limit 
and fault the connection if they are not. 

FRS360 When a Time Coordination Message is received; the producer shall check that the 
Time_Coordination_Section.Consumer_Time_Value is not the same as the last received 
Consumer_Time_Value. If it is, the Time Coordination message shall not be processed. 


TST80 The designer shall confirm that the Time value in the Time Coordination response is 
being applied to create the proper time offset on future time stamps. 


This inspection should be performed for all supported production services (ie. Multi-cast and 
single-cast). 


TST81 The designer shall confirm via design review or inspection that the 
Time_Drift_Since_Last_Time_Coord is being measured and used to in cases to calculate Time 
Correction Values when needed. Also the designer shall confirm that a drift value is kept for 
each multi-cast consumer. 


TST82 The designer shall confirm via design review or inspection that the 
Producer_Rcved_Time_Value is implemented as required. 

TST83 The Designer shall confirm via design review or inspection that the 
Ping_Int_Since_Last_T_Coord_Msg_Count is incremented correctly for single-cast and multi- 
cast, plus the designer shall confirm it gets reset when Time Coord messages are received. The 
lesigner shall also confirm that this parameter is used to fault the connection when the Time 
Coord Msg is not received within the proper time period. 


TST85 - Producer Parameter Calculations 


Requirement A 
Nabe: Requirement 
FRS245 The Time_Drift_Constant calculation shall be done using at least 32 bit integer math with 
the result being a 16 bit integer. 
FRS247 The Time_Coord_Response_EPI_Limit calculation shall be done in 32 bit integer math 
with the result being a 16 bit integer. 


TST85 The designer shall confirm by inspection or design review that the 
Time_Drift_Constant and Time_Coord_Response_EPI_Limit calculation is done with the 
required mathematical accuracy 
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F-4.3.5 


F-4.3.6 


TST86 - Safety Producer/A pplication Interface 


Requirement 7 
Naniber Requirement 

FRS123 Safety_Data_Out is produced at a periodic rate, referred to as the Expected Packet Interval 
(EPI). The Safety ValidatorClient shall sample, capture, and time stamp the data to be sent 
every EPI time period. 

FRS124 The producing application provides Safety_Data_Out to the SafetyValidatorClient. The 
Safety ValidatorClient shall build the Mode_Byte, Actual_Data, and Complement_Data, 
and Time stamp section (see section 5.7.1 for formats). 

FRS125 The Safety ValidatorClient shall provide safety connection status back to the producing 
application for each consumer. 

FRS217 The producer connection status shall be determined by the combination of the 
S_Connection_Fault and the Consumer_Active_Idle flags (Refer to Table 2-4.1) 

FRS219 If a safety data producer is producing data and valid Time Coordination information has 
been received without errors the Consumer_Active_Idle flag shall be equal to Active, 
otherwise it will be Idle. 

FRS220 For multi-cast producers, a Consumer_Active_Idle flag shall exist for each multi-cast 
consumer, numbered | through Max_Consumer_Number. 

FRS221 At connection establishment, all Consumer_Active_Idle flags shall be initialized to Idle. 

FRS222 An S_Connection_Fault indication of Fault, shall indicate that the producer has detected a 
problem with the safety connection to this consumer or the consumer has indicated an error 
back to the producer. 

FRS223 If the safety data producer has received invalid Time Coordination information, Time 
Coordination information with a Con_Detected_Fault set to Faulted, or a Time 
Coordination information timeout, the S_Connection_Fault flag shall be equal to Fault, 
otherwise it will be OK. 

FRS224 For multi-cast producers, a S_Connection_Fault flag shall exist for each multi-cast 
consumer, numbered 1 through Max_Consumer_Number. 

FRS225 At connection establishment, all S_Connection_Fault variables shall be initialized to OK 

FRS250 Producer_Safe_Data_TS is a variable that shall be set equal to Producer_Clk_Count at the 


point in time that the Safety_Data for a particular EPI data production is sampled and 
captured from the producing application. 


TST86 The Designer shall confirm that the Safety Producer captures the latest data for each 
EPI production and provides timely consumer connection status back to the application. The 
designer shall confirm that the captured data is reflected in the true and complement data 
sections, and the status is derived properly. 


TST87 - Connection Establishment — RunTime Coordination 


Requirement 


Nammbex Requirement 

FRS322 For Safety Data producers, Consumer_Open from the Validator Connection Establishment 
Engine to the Run Time Validator shall be provided to indicate whether or not a particular 
consumer of the produced data has an active open connection. 

FRS323 Tf the producer is multi-cast, Consumer_Open shall exist for each multi-cast consumer, 1 
through Max_Consumer_Number (indexed from 0 to Max_Consumer_Number - 1). 

FRS324 The Consumer_Open indication shall act as an enable to the Run Time Validator on a 
connection by connection basis. After successful connection establishment, Consumer_Open 
flags shall transition from Closed to Open. 

FRS326 The Validator Connection Establishment engine shall provide an array of consumer 


connection status resources for multi-cast producers that shall be allocated when a consumer 
makes a connection. 
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F-4.3.7 


F-4.4 


F-4.5 


F-4.6 


Requirement A 
Naaihee Requirement 
FRS327 The consumer numbers (refer to A.4.1) allocated to a Run-time validator shall be the number 
sent to the consumer in the connection establishment reply. 


TST87 The designer shall confirm that the connection establishment engine communicates 
connection status properly. 


TST127 - Extended Format Connection Establishment 


Requirement ; 
Number Requirement 
FRS361 Safety Originators that connect with an EtherNet/IP target or a DeviceNet target with an 


Ethernet/IP hop within the path and have an RPI of greater than 100 ms shall use the 
Extended Format. 


TST127 Designers of safety originators shall assure that a strategy is in place such that if an 
RPI greater than 100 ms is selected and the connection runs over EtherNet/IP that the Extended 
Format will be used. 


TST88 - Safety Supervisor Behavior 


Requirement 
Wanner Requirement 

SRS66 The state behavior of the Safety Supervisor object shall control the state of entire device. 
All objects in a safety device are required to be subservient to the states and commands of 
the Safety Supervisor to manage its functions and behaviors. 

SRS142 All CIP safety devices shall replace the Identity object state behavior with the behavior 
defined in the Safety Supervisor object 

SRS187 For safety devices which use the SNCT interface, the states of the Safety Supervisor shall 
be what determine the Module LED status. 


TST88 The designer shall confirm by inspection or design review that the device behavior is 
controlled by the safety supervisor. 


TST 106 - Safety Supervisor Reset Password 


Requirement A 
Name Requirement 

SRS23 The SNCT interface shall provide a Reset Password service which takes a vendor specific 
field to reset the password 

FRS346 If a Data Size error occurs in the Safety Supervisor Reset_Password command, either error 
code 0x15 (too much data) or 0x13 (not enough data) shall be returned. 

FRS347 If a Vendor data mismatch occurs when processing a Safety Supervisor Reset_Password 
command, a Privilege Violation error code (OxOF) shall be returned. 


TST 106 The designer shall confirm by functional test that the device correctly implements the 
Reset Password service 


TST89 - Safety Validator Behavior 


Requirement 5 
Nawber Requirement 
SRS80 A Validator shall only accept connections when the Safety Supervisor is in the state that 
can accept connections which is device dependent (i.e. Executing only, or Execute/Idle) 
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TST89 The designer shall confirm by inspection or design review that the validator will not 
process/accept safety connections while the safety supervisor is in a state which doesn’t allow 
it. 
F-4.7 TST90 - Corrupted Message Handling 
Requirement 5 
‘Naraber Requirement 
FRS85 If a corrupted message is detected at the standard layer, it shall be discarded and not 
presented to the application. 
TST90 The designer shall confirm that the device will drop corrupted packets and prevent the 
data from reaching the application. 
F-4.8 TST91 - Major Fault Effect on Safety State 
Requirement 7 
wane Requirement 
FRS120 A failure in a background communications diagnostic shall cause all producer/consumer 
safety connections for that device to be terminated. 
FRS121 If there is a major fault in a safety device that causes the device to go into a safety state, the 
device shall be reset or restarted. 
FRS122 In order to clear a major faults in a system the device shall execute and pass all internal 
self-tests prior to accepting or initiating any safety connections. 
TST91 The designer shall confirm that the device drops all safety I/O connections when a 
diagnostic failure is detected, and doesn’t allow them to restart without a reset. 
F-4.9 TST92 - Configuration Integrity Test 
Requirement 2 
NGnibER Requirement 
SRS37 For Type | configured or tool configured devices, configuration validation of the 
downloaded safety-relevant data from the software (or originator) shall be performed with 
SIL3 integrity 
SRS40 SIL3 devices shall store/restore its configuration data with SIL3 integrity 
SRS41 SIL3 devices shall handle all device state transitions with SIL3 integrity 
SRS90 The SCCRC shall be calculated over the configuration data by the device whenever a 
device configuration is validated (i.e. Validation Request to the safety supervisor or type 1 
safety connection) 
SRS91 The SCCRC shall be saved to NV storage along with the other NV attributes whenever a 
configuration is applied (i.e. apply request to the safety supervisor). 
SRS124 The reading of the UNID attribute in the Safety Supervisor shall be done with safety 
integrity. 
SRS125 The applying of configuration data and UNID to NVS shall be done with safety integrity. 
TST92 The designer shall confirm via inspection or design review that the configuration 


validation and SCID calculations are done with SIL3 integrity 
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F-4.9.1 


F-4.10 


F-4.10.1 


F-4.11 


TST47 — CPCRC Handling in Originators 


Requirement x 
Naber Requirement 
SRS93 The Connection Parameter CRC attribute shall be calculated by this originator device 
whenever the originator’s configuration is validated (i.e. Validation request to the safety 
supervisor). 
SRS94 The CPCRC shall be saved to NV storage along with the other NV attributes whenever a 
configuration is applied (i.e. apply request to the safety supervisor). 


TST47 The CPCRC Handling Test in Originators shall confirm that the originator calculates 
and stores the CPRC properly when the configuration changes. 


TST93 - Safety Device Hardware Validation Tests 


Pe? Requirement 
FRS244 The clocks in safety devices shall be accurate to within 0.02% (0.0002) 
FRS248 Each product that produces or consumes safety data shall derive a periodic timer that 
increments a counter (Producer_Clk_Count or Consumer_Clk_Count) every 128 uSecs. 
FRS249 Producer_Clk_Count (and Consumer_Clk_Count) shall be 16 bits in length. 


TST93 The designer shall confirm via inspection or design review that the clock has a 128 uS 
tick rate into a 16-bit register with an accuracy within the required 0.05% 


TST94 The product design/specification shall insure that it implements both a Module Status 
and Network Status LED. 


TST103 - Switch Behavior Tests 


Requirement 5 
Number Requirement 
SRSI11 When the switches are read, if the specified MAC ID differs from the value stored in the 


DeviceNet object’s MAC ID Attribute (NVRAM values), the appropriate attribute/s shall 
be updated and saved to NVRAM. 


TST103 The designer shall confirm that if MacId switches are used, the required behavior is 
implemented 


TST95 - Configuration Software Tests 


Requirement ‘i 
NanbEE Requirement 

FRS111 The SNCT which generates a safety device configuration shall generate a unique Safety 
Configuration Identifier 

FRS161 The SCTS shall be a Time/Date stamp marking the Time & Date of the configuration 
creation or change. 

FRS162 The configuration software shall follow the CIP defined Date and Time format (IEC 1131- 
3) for setting the signature. 

SRS1 The configuration Software for a Safety Connection Originator shall provide a means for 
the following parameters to either be configured or given default values: Expected Packet 
Interval, Target UNID, Originator UNID, Timeout_Multiplier, Ping Interval EPI Multiplier, 
Time Coord Msg Min Multiplier, Max Consumer Number, Network Time Expectation 
Multiplier, ASYNC, Max_Fault_Number (Extended Format only) 

SRS21 Software shall transparently insert “password” in all services which require one until a user 
sets it to something different 
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Requirement i 
Naiaber Requirement 

SRS39 The SNCT software shall provide a facility to allow the user to confirm downloaded 
configurations are correct. 

SRS47 The SCID shall change when a device’s configuration data changes. 

SRS49 If a SYNC parameter is not defined in a Device’s EDS file, the software shall use a default 
value of |. 

SRS71 SNCT shall always use all OxFF for the OUNID 


TST95 The Software Designer shall confirm that certain key requirements are being met by the 
software. 


ig Confirm the Time&Date Timestamps are generated when a new configuration is created 
or changed. 


2: Confirm the Time&Date value generated uses the IEC 1131-3 format. 


F-4.11.1_ TST46 - Incorrect Parameter Tests for Originator Connection Configuration 


Requirement A 
NGS Requirement 

FRS230 The legal range of the base format Timeout_Multiplier values shall be 1, 2, 3, or 4. 
The legal range of the Extended Format Timeout_Multiplier value shall be 1 to 255 so long 
as the Network Time Expectation value does not exceed 5.8 seconds. 

FRS231 For any producer, each producer connection and the corresponding consumer connection(s) 
shall be of the same Connection Type. 

FRS235 A legal Ping_Interval_EPI_Multiplier shall have a minimum value determined from the 
equation Max_Consumer Number*Timeout_Multiplier.PI +15, and a maximum less than 
1000. The default values shall be 100 for Multi-cast and 19 for Single Cast 

FRS239 The Ping_Interval_EPI_Multiplier shall be greater than or equal to: 
[{the Max Timeout_Multiplier.PI(C#) for all consumers} * Max_Consumer_Num] + 15 

FRS241 If the connection type is single-cast, the Max_Consumer_Number shall be equal to 1. 

FRS242 For multi-cast connections, the legal range of Max_Consumer_Num values shall be from 1 
through 15. 

FRS243 The default for the Time_Coord_Msg_Min_Multiplier shall be 0, and the legal range of 
values shall be from 0 through 7813, which equates to 0 through 1 Sec 

FRS318 The Ping_Interval_EPI_Multiplier shall be set small enough to ensure that the 
Ping_Count_Interval is less than or equal to 100 seconds. 

SRS85 Devices implementing the safety extensions to the CCO object shall perform a range check 
on the Ping Interval EPI Multiplier during a Validation request 

SRS86 Devices implementing the safety extensions to the CCO object shall perform a range check 
on the Time_Coord_Msg_Min_Mulitiplier during a Validation request. 

SRS87 Device implementing the safety extensions to the CCO object shall perform a range check 
on the Network_Time_Expectation_Multiplier during a validation request. 

SRS88 Device implementing the safety extensions to the CCO object shall perform a range check 
on the Timeout_Multiplier during a validation request. 

SRS89 Device implementing the safety extensions to the CCO object shall perform a range check 
on the Max Consumer Number during a validation request. 


TST46 The Incorrect Parameter test shall set the SafetyOpen parameters to invalid or out-of- 
range values and confirm proper detection in the originator at configuration time. 
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The following sequence should be performed: 


1. 


Note: 


Request Safety Reset type 1. 

Pass: Success_Response. 

Request Propose/Apply valid TUNID. 
Pass: Success_Response. 

Request Configure_Request. 

Pass: Success_Response 

Request Create service with valid data 


Pass: Success_Response, instance ID. 


Request Set_Attributes_All service, specifying a Timeout Multiplier = 8 (value 1). 


For each of the following Set_Attributes_All requests, expected responses are: 


Pass: Success_Response, or Error_Response, 09, Invalid Attribute Value. 


If Success_Response, Request Validate_Configuration. 


Pass: Error_Response, DO 02 


Request Set_Attributes_All service, with Transport Class = 1, 2, 3, 4, 5, 6, 7. 
Request Set_Attributes_All service, with Transport Trigger = 0, 1, 3, 4, 5, 6,7. 


Request Set_Attributes_All service, wit 


Request Set_Attributes_All service, wit 
value). 


Request Set_Attributes_All service, witl 
= 200ms. 


Request Set_Attributes_All service, witl 


Ping_Interval_Multiplier = invalid min value. 


Ping_Interval_Multiplier = 1001 (invalid max 
Ping_Interval_Multiplier = 1000 and data RPI 


TimeOut Multiplier = 4 for base format 


connections and Timeout_Multiplier = 255 for Extended Format connections, 


MaxConsumers =15, Ping _Interval_ EP’ 


Request Set_Attributes_All service, witl 
3. 


Request Set_Attributes_All service, wit 
17. 


T_Multiplier = 70. 


a Single Cast connection and MaxConsumers = 


a Multi Cast connection and MaxConsumers = 


Request Set_Attributes_All service, with Time Coord Min Message Multiplier = 8000. 


Request Set_Attributes_All service, witl 
MaxConsumers = 15, data RPI = 2ms. 


Time Coord Min Message Multiplier = 0, 
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F-4.12 TST96 - EDS File Requirements 


Requirement ‘ 
Namber Requirement 

SRS206 The EDS file for safety devices shall include a [Device Classification] section which shall 
contain a Classx keyword that indicates the Safety classification. 

SRS207 An “EDSFileCRC=” keyword and value shall be included in all safety device EDS files. 

SRS208 A “SafetyCfgAssemby=" keyword entry shall be included for Safety devices that are 
configured yia EDS file. This value shall also match an AssemN entry keyword specified 
in the [Assembly] section. 

FRS349 Safety devices that are configured via EDS file shall define a Configuration Assembly 


TST96 The EDS Checker shall confirm the EDS file contain all the required entries for safety 
devices. 


F-4.13 TST97 - Safety Manual Inspection Requirement 


Requirement 


NGmRDSE Requirement 


FRS112 The user safety manual shall contain instructions instructing the user “The replacement of 
safety devices requires that the replacement device be configured properly and operation of 
the replacement device shall be user verified. 


FRS103 The safety manual shall contain user instructions that state “If you choose to configure 
safety connections with an SCID=0, you are responsible for ensuring that originators and 
targets have the correct configurations”, or similar equivalent wording. 


FRS154 The user safety manual shall contain an advisory that states “The user should assign SNN. 
numbers for each safety network or safety sub-net that are unique system-wide”, or words 
to that effect. 


SRS38 When a SIL3 device is configured directly from a workstation, the device safety manual 
shall instruct the user to compare the transferred SCID and configuration data with the 
SCID and configuration data originally viewed in the workstation. 


SRS42 The device Safety Manual shall contain an advisory that user testing is the means by which 
all downloads are validated 


SRS43 The device Safety Manual shall contain an advisory that the signature should only be 
considered “verified” (and configuration locked) after user testing 


SRS44 The device User manual shall contain an advisory that configuring an originator with 
connection data and/or target configuration data must be downloaded to the target so it can 
be tested and verified. Only then can SCIDs from the target be confirmed. 


SRSSO The safety manual shall contain a user instruction requiring the user to completely test a 
device’s operation before setting the Lock Attribute 


SRSS51 The safety manual shall contain a user instruction requiring the user to upload and compare 
the configuration from each affected safety devices to that which was sent by the SNCT 
before setting the Lock Attribute in those devices. 


SRS52 The safety manual shall contain a user instruction requiring the user to clear any pre- 
existing configuration from any safety device before installing it onto a safety network. 


SRS53 The safety manual shall contain a user instruction requiring the user to commission all 
safety devices with Macld (and Baud Rate if necessary) prior to installing it onto a safety 
network 


SRS92 The user shall be instructed in the safety manual to test safety connection configurations 
after they are applied in an originator to confirm the target connection is operating as 
intended. 
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Requirement A 
Naiabee Requirement 

SRS105 The User Safety Manual shall provide a warning that states “LEDs are NOT reliable 
indicators and cannot be guaranteed to provide accurate information. They should ONLY 
be used for general diagnostics during commissioning or troubleshooting. Do not attempt 
to use LEDs as operational indicators”. 

SRS193 The Safety manual shall contain a user warning advising that originators that have an 
“automatic” SNN setting feature should only use that feature when the safety system is not 
being relied upon. 

SRS202 Devices that can be configured via the SNCT interface shall include a safety manual 
advisory that instructs the user to lock the device after verification has been completed. 

SRS203 Devices that can be configured by a Type 1 SafetyOpen shall include a safety manual 
advisory that instructs the user to verify that all originator-configured safety devices have 
their ownership assignments as part of the final verification process. 

SRS204 All CIP safety devices shall include a safety manual advisory that instructs the user to 
visually verify that all configuration data was downloaded correctly. 


TST97 The Safety Manual review shall confirm that it contains the required safety statements. 


F-4.14 TST98 - Requirements Not Tested at this time 


The following requirements do not have tests defined. 


Requirement > 
Number Requirement 
SRS186 CIP Safety Device shall provide a separate Module Status LED and a Network Status LED. 


In this case, these indicators provide important additional safety-related information to the 
user that cannot be accomplished with a combined Net/Mod Status indicator. 


TST98 This is a placeholder for requirements that shall not be tested 


F-4.15 TST12 - Origination of Off-link Connection Test 


Requirement 


Number Requirement 
FRS169 DeviceNet originators shall use the connection manager Forward_Open service (with 
“Safety” Network Segment extension) when the target is not on the local network segment. 
FRS172 On DeviceNet, the originator shall establish an explicit messaging connection with the 


router or end-node to deliver the Forward_Open or SafetyOpen service requests. 


TST12 The Off-link Connection test shall simulate an off-link target to test a DeviceNet 
client’s use of the Forward_Open via and explicit connection to the bridge. 


The follow procedure will be used: 


1. Set up the tester to reside on an off-link subnet with an appropriate bridge or router 
linking the subnets 
2. Configure the originator DUT with a device configuration file and representative 
connection parameter set 
3: Trigger the DUT to make connections 
Confirm the DUT first opens an Explicit Message connection 
5. Confirm a standard Forward Open with a Safety Segment is sent over the explicit 
connection 
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F-4.15.1 Test Numbers Removed 


The following tests numbers do not exist in this document. Some were removed during the 
initial development of the Test Guide, others were consolidated into other tests. This section 
documents the test numbers that have no associated Tests defined. Test numbers: 11, 12, 35, 
46,47, 49, 59 
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Safety Test Matrix 

This section contains a matrix that cross references the tests defined in the Safety Test Guide to the behaviors that may be implemented in a safety 
device. Use the behaviors at the top of the matrix to determine which tests must be applied to the safety device. If there is a discrepancy between the 
Safety Test Matrix and the specification in the main sections of this volume then the specification shall take precedence. 


F-5.1 Safety Test Matrix 


Standard DeviceNet Conformance 


Standard EtherNevIP Conformance 
‘Type 2 Connection Est. Pos. Test 2 Target | xX x x | Ro | Ro | Ro 
Extended Format Type 2 
Connection Est. Pos. Test 113 Target im Be RO. RO 
Connection Initialization Test 3 | Target | xX x x ROPFS | ROPFS 
Connection Parameters CRC 
Need re 4 | Target | x x x ROPFS | ROPFS 
Type 2 SCID Check 5 Target xX xX xX ROPFS | ROPFS 
Electronic Key Mismatch 6 | Target |X Xx x ROPFS | ROPFS 
‘Target Connection ID Allocation 7 | Target | x % x ROPFS | ROPFS 
Multi-cast Producer, Consumer 
Number Allocation Bong [PMB 8 i # RORES 
Producer Multi-Cast Time 
Cone 99 | Target | x x x 
DeviceNet Extended Format Multi- 
cast producer formats, seeding & 120 | Target x x x 
connections 

-F-117- 

Edition 2.3 


SITE SUBSCRIPTION ONLY; SUBSCRIPTION RIGHTS OUTLINED ON PAGE (iii) 


Volume 5: CIP Safety, Appendix F: Safety Test Plan 


Type 2 Single-Cast Connection com 5& as 
Generation Test on DeviceNet 2, || nesaaton) ce a ROEFS | ROFES 
Type 2 Single-Cast Connection = ; 
Generation Test on EtherNev/IP EIBS #|Onginaton) fo = ROBES | ROPES. 
Type 2 Multi-cast Connection 3 
Generation on DeviceNet Op [Oneinster| x BOERS, 
Type 2 Multi-cast Connection ae 
Generation on EtherNev/IP 119, 1}Ongiaator| 2 2 me ROFFS 
Type 2 Extended Format Single- 114 loviginatr 7 7 20. | RO 
cast Connection Generation 
Type 2 Extended Format Multicast | 115 |ogiginator z - zo. 
Connection Generation 
Electronic Key Generation Test 100 Originator] xX x x ROPFS | ROPFS | ROPFS 
SafetyClose Processing by Targets | 101 | Target |X x x ROPES | ROPFS | ROPFS 
Connection Enable/SafetyClose 105 Originator] N/A | N/A | X RO, C6| RO, C6 | RO, C6 
Producer CRC & PID/CID Test 13. | Producer} X x 4 ROPES | ROPES ROPFS 
Orig Producer Packet Generation ~ ia). Freacen| Re 7 ee = - 
1 to 2 Bytes Data 
EF Producer Packet Generation-1] 199 | producer x = 7 ¥ 7 
to 2 Bytes Data 
Orig Producer Packet Generation - 
310-250 Bytes Data 15 | Producer} X x ca | C4 c4 
EF Producer Packet Generation - 3 
to 250 Bytes Data 110 _ | Producer x x ca | C4 c4 
tee Backs; Generation Mode! 16 | Producer] xX. x x ROPES | ROPFS ROPFS 
Producer Packet Time Stamp CRC 17 | Producer! X. x x x x 
Producer Time Correction CRC 18 | Producer} X x x ROPES 
Producer Time Correction M 
Byte & Mast Byte 2 19 | Producer} X x x 
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EF Producer Time Correction iat. Nipresiesee x << % ri 
Mcast Byte 
Base Format Producer Single-Cast 20 | Producer] X X Xx Xx Xx 
Extended Format Producer Single- | 451 | producer z x 7 = - 
Cast 
Producer Run/Idle Usage 21 | Producer} X x ce X__ [ROPES | ROPFS ROPFS 
Producer Ping Count Usage 22 | Producer} X x x X__ [ROPES | ROPFS ROPFS 
Base format Multi-Cast Production | 55 | progucer| x = 7 ¥ 
toa Single Consumer 
Extended Format Multi-Cast pire (Seen = = ” = 
Production to a Single Consumer 
Multi-Cast Production to Multiple su lieies| ¥ % z a 
Consumers 
Single east Consumes Tunes. 25 |Consumer| — X x x x ROPFS ROPFS 
Coordination Message Generation 
peaumee Positive CROPID(ID, 26 |Consumer|  X. x x ROPFS | ROPFS | ROPFS 
Multi-cast Consumer Time 
Coordination Message Generation 27 Consumer} X x x ROPFS 
Test 
Base format Consumer Incorrect ae eee ie = $ ¥ = x 
Sequence/Insertion Detection 
Extended Format Consumer 
Incorrect Sequence/Insertion 112 |Consumer| x x x x x x 
Detection 
TBD | TBD 

Consumer Message Corruption a. Weentatiel| = z x x Rone 
Detection ROPES | ROPFS 
\Consuiner Mestane'Deley 30 |Consumer|  X x x x ROPFS | ROPFS | ROPFS 
Detection 
Producer Time Coordination a ere < € x x wen 
Response Failure Test 
Extended Format Producer Time 
Coordination Response Failure 116 _ | Producer x x x x x TBD 
Test 
Producer Time Coordination No- TBD 
rests tek 32 | Producer! X x x x | ROPFS | ROPFS ROPFS 
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Base format Single-Cast Consumer 


Test; >= 3 Bytes, Negative Tests 33° [Consumer]! X x x c3 x 


Extended Format Single-Cast 
Consumer Test; >= 3 Bytes, 123 |Consumer x x x C3 x 
Negative Tests 


Base format Single-Cast 
Consumer; <= 2 Bytes, Negative 34 |Consumer|  X x x x x 
Tests 


Extended Format Single-Cast 


Consumer; <= 2 Bytes, Negative 124 |Consumer x x x x Be 
Tests 
Single: Cast Consimer 36 |Consumer| x x x ROPFS ROPES 
Communication Failure Test 
Base Format Multi-Cast Consumer | 47 |onsumer! xX e zx 
Negative Test 
Extended Format Multi-Cast | Sees a a x a 
38 |Consumer| Xx x x x 
Extended Formai Multi-cast 
Consumer PID/Rollover detection 125 «| Consumer * m x as 
Mult eft Consnimes 39 |Consumer| x x x x ROPFS 
Communication Failure Response 
Base format Multi-cast Consumer ae ee ae S x . 


‘Time Correction Negative Test 


Extended Format Mult 
Consumer Time Correction 126 |Consumer x x x x 
Negative Test 


Multi-cast Producer Time 
Correction Generation Negative 41 | Producer] -X x x x ROPFS 
Test 


TBD 
ROPFS 


[e) C9, C9, 


Configuration UNID 42 | Target | xX x x % | eoerel goes lnoes 
Paabisnent Tet a | tume | Xx fox |X |X [ropks| ropes | ROPES 
cama tree bs cups 44 | Target |X x x x ae 
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‘Type | Configuration from co, | C9, | C9, 
Originators 5, § [Onetnatoe) is be x ROPFS | ROPES | ROPFS 
: Orig 
Identity Object 48 | ee | NA] NA x x | RopD | ROPD | ROPD | ROPD | ROPD | ROPD 
ange 
; Orig/ RO, C9 | RO, C9 | RO, C9 | RO, C9 | RO, C9 | RO, C9 
Maeld, SNIN, UNID Benevict, FS ll ety |r oanae | os or C10 | or C10 | or C10 | or C10 | or C10 | or C10 
Orig/ RO, C9 | RO, C9 | RO, C9 | RO, C9 | RO, C9 | RO, C9 
TP seldress; SNN, UNID Behaviat 108: Target WA me X  Jorcio | or C10 | or C10 | or C10 | or C10 | or C10 
Orig/ 
Reset Switch sof ae, | NA | NA | x X — ]c2,R0| C2, RO | C2, RO | C2, RO] C2, RO | C2, RO 
range’ 
Orig 
104 N/A | N/A x x | RopD | ROPD | ROPD | ROPD | ROPD | ROPD 
Baseline Supervisor Test Target 
Propose/Apply TUNID & Reset ae Orisy Toa | oa x x | R2.C9) RO, C9 | RO, C9 | RO, C9 | RO, C9 | RO, C9 
‘Commands Target or C10 | or C10 | or C10 | or C10 | or C10 | or C10 
Orig/ ro, | Ro, | Ro, | Ro, | RO, | RO, 
Configuration Lock/Unlock 53 | target | NA | NA x E” Pcr- | ter. | Ser: [acto | “cab: |ci6 
Orig/ Ro, | RO, | RO, | RO, | RO, | RO, 
Configure Request 54 | ranger | NA | NA x Kl Weciee| Scie (ciel iseig: vere. ete 
Orig/ RO, RO, RO, RO, RO, | RO, 
SNCT Configuration Process 55 | carpet | NA | NA x % [creel weiss) ccion |) io |cios | kis 
Orig/ Ro, | RO, | RO, | RO, | RO, | RO, 
Setting Passwords 56 | target | NA | NA x 5 cor.’ |'cios| cio | cio eGio® | cei 
Orig Ro, | Ro, | RO, | Ro, | RO, | Ro, 
Mode Change 7 . N/A | N/A x x | cto, | cio, | cro, | cro, | cio, | co, 
Target cs | cs | cs | cs | cs | cs 
i Orig/ CF, | CR. PCr | C7,” | Cn. | Cr, 
Safety Validator Diagnostics 58 | target | NA | NA x X! earn | opp |RoED | Ron: |RosD |'RoRD 
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Dnet Bridge FW-O to S_Open eo | Bridge | wa | wa 5 s 
Forwarding 

Dnet Bridge nonDnet-to-Dnet «3 | Bridge | wa | NA x x 
Message Forwarding 

Dnet Bridge Dnet-to-NonDnet 64 Bridge NIA NIA x x 
Message Forw; 

Standard CIP Message Rejection 65 |Consumer| —-X x x x x x x | 
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